Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: green
Updated: 43 min 41 sec ago

https://yourfakebank.support -- TLD confusion starts!, (Tue, Sep 16th)

Tue, 09/16/2014 - 13:24

Pretty much ever since the new top level domain (TLD) ".biz" went online a couple years ago, and the only ones buying domains in this space were the scammers, we kinda knew what would happen when ICANN's latest folly and money-grab went live. It looks like a number of the "new" top level domains, like ".support", ".club", etc have now come online. And again, it seems like only the crooks are buying.

We are currently investigating a wave of phishing emails that try to lure the user to a copy of the Bank of America website. The main difference, of course, is that any login credentials entered do not end up with Bank of America, but rather with some crooks, who then help themselves to the savings.

Phishing emails per se are nothing new. But it appears that URLs like the one shown in the phishing email above have a higher success rate with users. I suspect this is due to the fact that the shown URL "looks different", but actually matches the linked URL, so the old common "wisdom" of hovering the mouse pointer over the link to look for links pointing to odd places .. won't help here.

But wait, there's more! Since the crooks in this case own the domain, and obviously trivially can pass the so-called "domain control validation" employed by some CA's, they actually managed to obtain a real, valid SSL certificate!

Quoting from the Certificate Authority's web site:

Comodo Free SSL is a fully functional Digital Certificate, recognized and trusted by 99.9% of browsers. Your visitors will see the golden padlock and won't see security warnings. What will you get:

  • Ninety day free SSL Certificate (other CAs offer 30 days maximum.)
  • Issued online in minutes with no paperwork or delays
  • Highest strength 2048 bit signatures / 256 bit encryption
  • Signed from the same trusted root as our paid certificates
  • Recognized by all major browsers and devices

They don't mention why they think any of this is a good idea.

Addition of SSL to the phish means that another "scam indicator" that we once taught our users is also no longer valid. When a user clicks on the link in the phishing email, the browser will actually show the "padlock" icon of a "secure site". See the screenshot below.

 

If you have seen other recent banking phishes that use new top level domains and/or valid SSL certificates, please let us know via the contact form, or the comments below!

 

 

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

Adobe updates, Reader and Acrobat --> http://helpx.adobe.com/security/products/reader/apsb14-20.html, (Tue, Sep 16th)

Tue, 09/16/2014 - 13:01
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Tuesday, September 16th 2014 http://isc.sans.edu/podcastdetail.html?id=4149, (Tue, Sep 16th)

Mon, 09/15/2014 - 19:03
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Spoofed SNMP Messages: Mercy Killings of Vulnerable Networks or Troll?, (Mon, Sep 15th)

Mon, 09/15/2014 - 18:50

2nd Update

All the packet captures we received so far show the same behavior. The scans are sequential, so it is fair to assume that this is an internet wide scan. We have yet to find a vulnerable system, and I don't think that vulnerable configurations are very common but please let me know if you know of widely used systems that allow for these SNMP commands. This could also just be a troll checking "what is happening if I send this". 

1st Update

Thanks to James for sending us some packets. Unlike suggested earlier, this doesn't look like a DoS against Google, but more like a DoS against vulnerable gateways. The SNMP command is actually a "set" command using the default read-write community string "private". If successful, it should:

- set the default TTL to 1, which would make it impossible for the gateway to connect to other systems that are not on the same link-layer network.

- turn off IP forwarding.

Still playing with this, and so far, I haven't managed to "turn off" any of my test systems. If you want to play, here are some of the details:

The SNMP payload of the packets reported by James:

Simple Network Management Protocol
    version: version-1 (0)
    community: private
    data: set-request (3)
        set-request
            request-id: 1821915375
            error-status: noError (0)
            error-index: 0
            variable-bindings: 2 items
                1.3.6.1.2.1.4.2.0:
                    Object Name: 1.3.6.1.2.1.4.2.0 (iso.3.6.1.2.1.4.2.0)
                    Value (Integer32): 1
                1.3.6.1.2.1.4.1.0:
                    Object Name: 1.3.6.1.2.1.4.1.0 (iso.3.6.1.2.1.4.1.0)
                    Value (Integer32): 2

 

The snmp set command I am using to re-create the traffic:

snmpset  -v 1 -c private [target ip] .1.3.6.1.2.1.4.2.0 int 1 .1.3.6.1.2.1.4.1.0 int 2

any insight is welcome. Still working on this and there may be more to it then I see now (or less...)

 

--- end of update ---

We are receiving some reports about SNMP scans that claim to originate from 8.8.8.8 (Google's public recursive DNS server). This is likely part of an attempt to launch a DDoS against Google by using SNMP as an amplifier/reflector.

Please let us know if you see any of the packet. The source IP should be 8.8.8.8 and the target port should be 161 UDP. For example in tcpdump:

tcpdump -s0 -w /tmp/googlensmp dst port 161 and src host 8.8.8.8

Thanks to James for sending us a snort alert triggered by this:

Sep 15 11:07:07 node snort[25421]: [1:2018568:1] ET CURRENT_EVENTS Possible Inbound SNMP Router DoS (TTL 1) [Classification: Attempted Denial of Service] [Priority: 2] {UDP} 8.8.8.8:47074 -> x.x.251.62:161

So far, it does not look like service to Google's DNS server is degraded.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

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

Even Bad Malware Works, (Mon, Sep 15th)

Mon, 09/15/2014 - 09:51

For a few weeks now, I keep receiving a few "Delta Ticket" e-mails a day with zipped executables as attachments. The e-mails are done about as bad as it gets:

  • The "From" address uses a random domain
  • The e-mail does not use the typical "Delta" formating/branding.
  • The attachment is a straight executable, just zipped.
  • Antivirus is ok on a new sample received right now (8/55 according to virustotal) and excellent (>30/55) on older samples. [1]
  • The e-mail (flight information) is very specific and does not appear to be customized to the sender
  • Delta doesn't send tickets as attachments like this.

So they could do a lot better. The sad part is, that they apparently have no need to do better.

The "From" name, which is what most people are looking at, reads "Delta Air Lines". Some major/popular AV tools still don't detect it well at all, and well, users like to click on stuff I guess.

The initial piece of malware appears to be a generic downloader. In my system, it installed what looked like a fake Adobe update. Still running it to see what is exactly going on, but not expecting too much.

 

[1] https://www.virustotal.com/en/file/4cf652e71bbbe37eecda58169471df27db15ca1e5a8f14006128a4883b095409/analysis/1410799974/
 

 

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

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

ISC StormCast for Monday, September 15th 2014 http://isc.sans.edu/podcastdetail.html?id=4147, (Mon, Sep 15th)

Sun, 09/14/2014 - 18:04
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

SSDEEP update, (Sun, Sep 14th)

Sun, 09/14/2014 - 06:17

Jesse Kornblum released a new version of his fuzzy hashing tool ssdeep this week.  This release fixes a problem that was apparently introduced with version 2.10 in July 2013.  If you use ssdeep, you are encouraged to update and if you have the time, you may want to recompute the v2.10 hashes in your database.

References:

http://jessekornblum.livejournal.com/295883.html

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

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

Are credential dumps are worth reviewing?, (Fri, Sep 12th)

Fri, 09/12/2014 - 15:53

It’s been reported that around five million Gmail email addresses were released on to a forum early on in the week. In the file, next to each email address, was a password. These email addresses and passwords appear to have been collected over a few years from multiple web site sources, not from a compromise of Gmail/Google.  The Google security team have done their analysis on the credential dump and alerted the two percent of those in that list they determine were at risk [1]. 

A fair number of researchers, academics and the curious will analyze, collate and build a number of models showing the most common and most amusing passwords and it’s probably something most of us have seen before. So what else can we gain from these types of credential dumps and can we make it worth out time reviewing them?

 

Here are a few suggestions to make use of these types of dumps in a more positive manner.

1) Showing non-security staff (i.e. the rest of the world) the top fifty most common passwords, with the number of people that use that same password, to provide a bit of user education on why not to use common passwords on their accounts, personal or work, or how reusing the same passwords across multiple sites can cause problems [2].

2) Providing you can get access to the full list, checking your email address isn’t there, and it would be nice to also check that people you know aren’t in the dump either.

3) A more business-focused approach, as long as you have permission, would be to compare all those email addresses against any Gmail registered user accounts, as an example any customers registered for your newsletters, logins to web sites or applications using Gmail accounts. If you do find any accounts that are linked to a listed Gmail email address from the dump, some possible options are:

  • Notify said users that their email address and a passwords has appeared on a credential dump
  • Force a password reset on that account
  • Audit and Monitor the accounts to see if unusual has occurred 

4) Another step after that would be to check your logs to see if there is any automated login attempts using the Gmail accounts against any of your systems, as this is well documented behaviour by various adversaries that fellow Handlers have reported upon previously [3]. 

 

If the information is out there, our adversaries are going to be using, so we should strive to ensure we have our incident response plans have how to deal with these external events quickly and with the minimum effort. 

 

[1] http://googleonlinesecurity.blogspot.com.au/2014/09/cleaning-up-after-password-dumps.html

[2] http://www.securingthehuman.org/blog/2012/07/30/guest-post-limits-of-password-security-awarneness

[3] https://isc.sans.edu/diary/Tales+of+Password+Reuse/17087 

 

Chris Mohan --- Internet Storm Center Handler on Duty

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

ISC StormCast for Friday, September 12th 2014 http://isc.sans.edu/podcastdetail.html?id=4145, (Fri, Sep 12th)

Thu, 09/11/2014 - 19:21
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

VMware NSX and vCNS product updates address a critical information disclosure vulnerability http://www.vmware.com/security/advisories/VMSA-2014-0009.html, (Fri, Sep 12th)

Thu, 09/11/2014 - 17:10

Chris Mohan --- Internet Storm Center Handler on Duty

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

ISC StormCast for Thursday, September 11th 2014 http://isc.sans.edu/podcastdetail.html?id=4143, (Thu, Sep 11th)

Wed, 09/10/2014 - 17:05
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Content Security Policy (CSP) is Growing Up., (Wed, Sep 10th)

Wed, 09/10/2014 - 15:58

We have talked here about Content Security Policy (CSP) in the past. CSP is trying to tackle a pretty difficult problem. When it comes to cross-site-scripting (XSS), the browser and the user is usually the victim, not so much the server that is susceptible to XSS. As a result, it makes a lot of sense to add protections to the browser to prevent XSS. This isn't easy, because the browser has no idea what Javascript (or other content) to expect from a particular site. Microsoft implemented a simple filter in IE 8 and later, matching content submitted by the user to content reflected back by the site, but this approach is quite limited.

CSP is an attempt to define a policy informing the browser about what content to expect from a site. Initially, only Firfox supported CSP. But lately, CSP has evolved into a standard, and other browsers started to implement it [1]. The very granular langauge defined by CSP allows sites to specify exactly what content is "legal" on a particular site.

Implementing CSP on a new site isn't terrible hard, and may actually lead to a cleaner site. But the difficult part is to implement CSP on existing sites (like this site). Sites grow "organically" over the years, and it is difficult to come back later and define a policy. You are bound to run into false positives, or your policy is relaxed to the point where it becomes meaningless.

Luckily, CSP has a mechanism to help us. You are able to define a "Report URL", and browsers will report any errors they encounter to said URLs. The reports are reasonably easy to read JSON snippets including the page that caused the problem, the policy they violated, and even an excerpt from the part of the page that caused the problem.

Recently, a few nice tools have cropped up to make it easier to parse these reports and build CSPs. For example Stuart Larsen implemented "CASPR" [2], a plugin for Chrome that was built to create CSPs and to analyze the reports. Tools like this make implementing CSPs a lot easier. 

Any other tools or resources you like to help implementing CSPs?

Update: We got a couple of additional resources in via Twitter:

Using "Virtual Patching" to implement CSP on your Web Application Firewall
Twitter account focusing on CSP: http://twitter.com/SeeEssPee

Thanks to @imeleven for pointing out that Firefox was the first browser to support CSP. He also pointed to this slide deck: http://www.slideshare.net/imelven/evolving-web-security-model-v11-portland-owasp-may-29-2014

​

 

[1] http://www.w3.org/TR/CSP/
[2] http://caspr.io

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

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

Content Security Policy (CSP) is Growing Up., (Wed, Sep 10th)

Wed, 09/10/2014 - 06:14

We have talked here about Content Security Policy (CSP) in the past. CSP is trying to tackle a pretty difficult problem. When it comes to cross-site-scripting (XSS), the browser and the user is usually the victim, not so much the server that is susceptible to XSS. As a result, it makes a lot of sense to add protections to the browser to prevent XSS. This isn't easy, because the browser has no idea what Javascript (or other content) to expect from a particular site. Microsoft implemented a simple filter in IE 8 and later, matching content submitted by the user to content reflected back by the site, but this approach is quite limited.

CSP is an attempt to define a policy informing the browser about what content to expect from a site. Initially, only Google Chrome supported CSP. But lately, CSP has evolved into a standard, and other browsers started to implement it [1]. The very granular langauge defined by CSP allows sites to specify exactly what content is "legal" on a particular site.

Implementing CSP on a new site isn't terrible hard, and may actually lead to a cleaner site. But the difficult part is to implement CSP on existing sites (like this site). Sites grow "organically" over the years, and it is difficult to come back later and define a policy. You are bound to run into false positives, or your policy is relaxed to the point where it becomes meaningless.

Luckily, CSP has a mechanism to help us. You are able to define a "Report URL", and browsers will report any errors they encounter to said URLs. The reports are reasonably easy to read JSON snippets including the page that caused the problem, the policy they violated, and even an excerpt from the part of the page that caused the problem.

Recently, a few nice tools have cropped up to make it easier to parse these reports and build CSPs. For example Stuart Larsen implemented "CASPR" [2], a plugin for Chrome that was built to create CSPs and to analyze the reports. Tools like this make implementing CSPs a lot easier. 

Any other tools or resources you like to help implementing CSPs?

[1] http://www.w3.org/TR/CSP/
[2] http://caspr.io

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

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

ISC StormCast for Wednesday, September 10th 2014 http://isc.sans.edu/podcastdetail.html?id=4141, (Wed, Sep 10th)

Tue, 09/09/2014 - 16:24
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Microsoft Patch Tuesday - September 2014, (Tue, Sep 9th)

Tue, 09/09/2014 - 11:22

Overview of the September 2014 Microsoft patches and their status.

# Affected Contra Indications - KB Known Exploits Microsoft rating(**) ISC rating(*) clients servers MS14-052 Cumulative Security Update for Internet Explorer Microsoft Windows, Internet Explorer

CVE-2013-7331 CVE-2014-2799 CVE-2014-4059 CVE-2014-4065 CVE-2014-4079 CVE-2014-4080 CVE-2014-4081 CVE-2014-4082 CVE-2014-4083 CVE-2014-4084 CVE-2014-4085 CVE-2014-4086 CVE-2014-4087 CVE-2014-4088 CVE-2014-4089 CVE-2014-4090 CVE-2014-4091 CVE-2014-4092 CVE-2014-4093 CVE-2014-4094 CVE-2014-4095 CVE-2014-4096 CVE-2014-4097 CVE-2014-4098 CVE-2014-4099 CVE-2014-4100 CVE-2014-4101 CVE-2014-4102 CVE-2014-4103 CVE-2014-4104 CVE-2014-4105 CVE-2014-4106 CVE-2014-4107 CVE-2014-4108 CVE-2014-4109 CVE-2014-4110 CVE-2014-4111 KB 2977629 Yes! Severity:Critical
Exploitability: 1 Critical Important MS14-053 Vulnerability in .NET Framework Could Allow Denial of Service Microsoft Windows, Microsoft .NET Framework

CVE-2014-4072 KB 2990931 No Severity:Important
Exploitability: 1 Important Important MS14-054 Vulnerability in Windows Task Scheduler Could Allow Elevation of Privilege Microsoft Windows

CVE-2014-4074 KB 2988948 No Severity:Important
Exploitability: 1 Important Important MS14-055 Vulnerabilities in Microsoft Lync Server Could Allow Denial of Service Microsoft Lync Server

CVE-2014-4068
CVE-2014-4070
CVE-2014-4071 KB 2990928 No Severity:Important
Exploitability: 1 Important Important We will update issues on this page for about a week or so as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY (*): ISC rating
  • We use 4 levels:
    • PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
    • Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
    • Important: Things where more testing and other measures can help.
    • Less Urt practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
    • The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threatatches.

       

-- 
Alex Stanford - GIAC GWEB & GSEC
Research Operations Manager,
SANS Internet Storm Center

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

ISC StormCast for Tuesday, September 9th 2014 http://isc.sans.edu/podcastdetail.html?id=4139, (Tue, Sep 9th)

Mon, 09/08/2014 - 18:50
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Monday, September 8th 2014 http://isc.sans.edu/podcastdetail.html?id=4137, (Mon, Sep 8th)

Sun, 09/07/2014 - 17:25
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Odd Persistent Password Bruteforcing, (Sun, Sep 7th)

Sun, 09/07/2014 - 15:43

This isn't something new, but I think it is often overlooked: "slow and low" password brute forcing.

One of the daily reports I like to look at is password brute force attempts. more or less "forever", A few networks stick out in these daily reports. The password brute force attempts are not particularly agressive, with usually less then 10 attempts per day from any particular IP address. The other odd thing is that the accounts being brute forced don't exist, which a heave focus on "@hotmail.com" accounts. 

By far the most agressive network is 193.201.224.0/22,"Besthosting" in the Ukraine, followed by an other Ukraining network, 91.207.7.0/24 (Steephost). 

The top brute forced domains:

    gmail.com
    outlook.com
    zfymail.com <- this domain is associated with many bots/spam messages.
    hotmail.com

The intend isn't perfectly clear as the accounts don't exist, and the attempts are not very aggressive (maybe to avoid getting locked out?). 

Anybody observing similar attacks and able to figure out what they are after?

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

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

ISC StormCast for Friday, September 5th 2014 http://isc.sans.edu/podcastdetail.html?id=4135, (Fri, Sep 5th)

Thu, 09/04/2014 - 17:18
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Identifying Firewalls from the Outside-In. Or, "There's Gold in them thar UDP ports!", (Thu, Sep 4th)

Wed, 09/03/2014 - 19:18

In a penetration test, often the key to bypassing a security control is as simple as knowing identifying the platform it's implemented on.  In other words, it's a lot easier to get past something if you know what it is.  For instance, quite often you'll be probing a set of perimeter addresses, and if there are no vulnerable hosts NAT-ed out for you, you might start feeling like you're at a dead end.   Knowing what those hosts are would be really helpful right about now.  So, what to do next?

Look at UDP, that's what.  Quite often scanning the entire UDP range will simply burn hours or days with not a lot to show for it, but if you target your scans carefully, you can quite often get some good information in a hurry.

Scanning NTP is a great start.  Way too many folks don't realize that when you make a network device (a router or switch for instance) an NTP client, quite often you also make it an NTP server as well, and NTP servers love to tell you all about themselves.  All too often that port is left open because nobody knows to block it.  

Another service that quite often bypasses all firewall ACLs is the corporate remote access IPSEC VPN specifically IKE/ISAKMP (udp/500).  Even if this is a branch firewall with a site-to-site VPN to head office, often IKE is misconfigured to bypass the interface ACL, or the VPN to head office is enabled with a blanket "any any" permit for IKE.

Let's take a look at these two sevices - we'll let's use NMAP to dig a little deeper.  First, let's scan for those ports:

nmap -Pn -sU -p123,500 --open x.x.x.x
Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-29 12:13 Eastern Daylight Time

Nmap scan report for some.fqdn.name (x.x.x.x)
Host is up (0.070s latency).
PORT    STATE SERVICE
123/udp open  ntp
500/udp open  isakmp

Nmap done: 1 IP address (1 host up) scanned in 46.69 seconds

OK, so we found open UDP ports - how does this help us?  Let's run the SECOND set of scans against these two ports, starting with expanding the NMAP scan to use the ntp-info script:

C:\ > nmap -Pn -sU -p123 --open x.x.x.x --script=ntp-info.nse

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-29 12:37 Eastern Daylight Time

Nmap scan report for some.fqdn.name (x.x.x.x)
Host is up (0.042s latency).
PORT    STATE SERVICE
123/udp open  ntp
| ntp-info:
|   receive time stamp: 2014-08-29T16:38:51
|   version: 4
|   processor: unknown
|   system: UNIX
|   leap: 0
|   stratum: 4
|   precision: -27
|   rootdelay: 43.767
|   rootdispersion: 135.150
|   peer: 37146
|   refid: 172.16.10.1
|   reftime: 0xD7AB23A5.12F4E3CA
|   poll: 10
|   clock: 0xD7AB2B15.EA066B43
|   state: 4
|   offset: 11.828
|   frequency: 53.070
|   jitter: 1.207
|   noise: 6.862
|_  stability: 0.244

Nmap done: 1 IP address (1 host up) scanned in 48.91 seconds

Oops - ntp-info not only tells more about our host, it also discloses the NTP server that it's syncing to - in this case check that host IP in red - that's an internal host.  In my books, that can be rephrased as "the next target host", or maybe if not next, at least on the list "for later".  Interestingly, support for ntp-info requests positions this host nicely to act as an NTP reflector/amplifier, which can then be used in DDOS spoofing attacks.  The send/receive ration is just under 1:7 (54 bytes sent, 370 received), so not great, but that's still a 7x amplification which you can spoof.

Back to the pentest - ntp-info gives us some good info, it doesn't specifically tell us what OS our target host is running, so let's take a look at IKE next, with service detection enabled:

C: \> nmap -Pn -sU -p500 -sV --open x.x.x.x

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-29 13:10 Eastern Daylight Time

Nmap scan report for some.fqdn.name (x.x.x.x)
Host is up (0.010s latency).
PORT    STATE SERVICE
500/udp open  isakmp
Service Info: OS: IOS 12.3/12.4; CPE: cpe:/o:cisco:ios:12.3-12.4

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 159.05 seconds

Ah - very nice!  Nmap correctly tells us that this device is a Cisco Router (not an ASA or any other device)


The ike-scan utility should give us some additional IKE info, let's try that with a few different options:

A basic verbose assess (main mode) gives us nothing:

C: > ike-scan -v x.x.x.x
DEBUG: pkt len=336 bytes, bandwidth=56000 bps, int=52000 us
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
x.x.x.x    Notify message 14 (NO-PROPOSAL-CHOSEN) HDR=(CKY-R=ea1b111d68fbcc7d)

Ending ike-scan 1.9: 1 hosts scanned in 0.041 seconds (24.39 hosts/sec).  0 returned handshake; 1 returned notify

Ditto, main mode IKEv2:

C: > ike-scan -v -2 x.x.x.x
DEBUG: pkt len=296 bytes, bandwidth=56000 bps, int=46285 us
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
---     Pass 1 of 3 completed
---     Pass 2 of 3 completed
---     Pass 3 of 3 completed

Ending ike-scan 1.9: 1 hosts scanned in 2.432 seconds (0.41 hosts/sec).  0 returned handshake; 0 returned notify

with just nat-t, still nothing:

C: > ike-scan -v -nat-t x.x.x.x
DEBUG: pkt len=336 bytes, bandwidth=56000 bps, int=52000 us
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
x.x.x.x    Notify message 14 (NO-PROPOSAL-CHOSEN) HDR=(CKY-R=ea1b111d8198ef48)

Ending ike-scan 1.9: 1 hosts scanned in 0.038 seconds (26.32 hosts/sec).  0 returned handshake; 1 returned notify

Aggressive mode however is a winner-winnner-chicken-dinner!

C: > ike-scan -v -A x.x.x.x
DEBUG: pkt len=356 bytes, bandwidth=56000 bps, int=54857 us
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
x.x.x.x    Aggressive Mode Handshake returned HDR=(CKY-R=ea1b111d4f1622a2)
SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=2
8800) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=afcad71368a1f1c96b8
696fc77570100 (Dead Peer Detection v1.0) VID=1fdcb6004f1722a231f9e4f59b27b857 VI
D=09002689dfd6b712 (XAUTH) KeyExchange(128 bytes) ID(Type=ID_IPV4_ADDR, Value=x.x.x.x) Nonce(20 bytes) Hash(20 bytes)

Ending ike-scan 1.9: 1 hosts scanned in 0.068 seconds (14.71 hosts/sec).  1 returned handshake; 0 returned notify

We see from this that the remote office router (this is what this device is)  is configured for aggressive mode and XAUTH - so in other words, there's likely a userid and password along with the preshared key to authenticate the tunnel.  Note that ike-scan identifies this host as "Cisco unity", so while it gives us some new information, for basic device identification, in this case NMAP gave us better info.

What should you do to prevent scans like this and the exploits based on them?  The ACL on your perimeter interface might currently end with a "deny tcp any any log" - consider adding on "deny udp any any log", or better yet, replace it with "deny ip any any log".  Permit *exactly* what you need, deny everything else, and just as important - LOG everything that gets denied.  Logging most of what is permitted also is also a good idea - if you've ever had to troubleshoot a problem or backtrack a security incident without logs, you are likely already doing this.

Adding a few honeypots into the mix is also a nice touch.  Denying ICMP will often defeat scripts or cursory scans.  Many network devices can be configured to detect scans and "shun" the scanning host - test this first though, you don't want to block production traffic by accident with an active control like this.

Have you found something neat in what most might otherwise consider a common and relatively "secure" protocol?  Please, use our diary to share your story !

===============
Rob VandenBrink
Metafore

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