Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: green
Updated: 10 min 32 sec ago

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

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

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

F5 BigIP Unauthenticated rsync Vulnerability, (Wed, Sep 3rd)

Wed, 09/03/2014 - 05:39

The reason I decided to write up this vulnerability is not the fact that this is a very popular system, or that there is a huge risk here. The main reason is that it struck me with a certain amount of sadness that we still have to deal with this problem in 2014. For example, I found an rsync configuration guide from 1999 that recommends the use of rsync over ssh [1].

F5 uses rsync to synchronize configurations if the BigIP load balancer is used in high availability mode. Sadly, the rsync server that is used for this does not require any authentication. As a result, an attacker can upload and download arbitrary files. The proof of concept exploit uploads an "authorized_keys" file permitting the attacker to ssh to the device and obtaining full shell access. In order to be vulnerable, the interface used to synchronize the devices has to be exposed [2].

F5 made a patch available [3].

But I think the lesson is larger then "Patch F5". This is about not forgetting history. In many of our classes, a complaint is why we include some older vulnerabilities. For example our "Securing Unix" class is going over some of the issues with "r" services like "rsh" and how to automate almost anything using ssh. 

What should you do? As a first step, a quick scan of your network for open rsync servers (port 873 tcp). Next, if you use ssh as you should, take a look at how you manage ssh keys as this is the next big problem. Are you keeping your secret keys in one (and only one) secure spot? Do you use different keys for different purposes? This can be a larger project to work out and implement correctly.

[1] http://everythinglinux.org/rsync/
[2] http://www.security-assessment.com/files/documents/advisory/F5_Unauthenticated_rsync_access_to_Remote_Root_Code_Execution.pdf
[3] http://support.f5.com/kb/en-us/solutions/public/15000/200/sol15236.html

---

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 3rd 2014 http://isc.sans.edu/podcastdetail.html?id=4131, (Wed, Sep 3rd)

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

Firefox 32 released, time to update - now with support for Public Certificate Pinning. Release notes here: https://www.mozilla.org/en-US/firefox/32.0/releasenotes/, (Tue, Sep 2nd)

Tue, 09/02/2014 - 16:01

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

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

"Death" of Internet Services, (Tue, Sep 2nd)

Tue, 09/02/2014 - 08:13

No, we're not talking about 1940's literature today - I've been reading, as have many, that Microsoft is planning to finally stop the venerable MSN Messenger Chat service. I find it interesting that the press is touting that MSN has few users left.  This might be true in our community, and I wouldn’t doubt that almost every demographic has moved away from MSN to other chat services like SMS on phones, Facebook, Skype, Twitter or whatever.

But maybe Toronto is an internet backwater or something – for every IPS stand up or egress filter I configure, in any company I’ll still find a handful of MSN Messenger users.  While we're seeing generally low activity on the main port used by MSN (1863) , we still see spikes in traffic - https://isc.sans.edu/port.html?port=1863

Do internet services ever die naturally?  It seems to me that folks hang on to what they know like grim death, and only give up services when they’re terminated forcibly.  

As a penetration tester, these older services can be a gold mine.  To me, older services (not to pick on any one service in particular) quite often are clear-text, so if you can get a clean packet capture then you've got a very good shot at harvesting credentials.  And we know for a fact that folks will tend to re-use credentials - userid's are easy to derive, but if you can harvest passwords on one service, you've got an excellent chance at re-using them to compromise another application or service.

Again, I'm not sure if it's just me, but I also tend to see that users of these older "consumer" type applications like this for some reason seem to be clustered in the upper echelons of many companies.  In other words, some of the best targets (politically at least) are using some of the most easily compromised applications.

Password re-use, prefering old/known applications to new ones, and "user clustering" around older apps - are you seeing this same trends?  

Did xkcd get it right?  http://xkcd.com/1305/

Please, use our comment form and let us know what you're seeing, both on MSN messenger or on other "old" internet applications!

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

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

Apple iCloud Security Incident, (Tue, Sep 2nd)

Tue, 09/02/2014 - 03:57

There's lots of interest in the recent iCloud incident, where apparently several "celebrity" accounts were compromised.

Sorry to say, it's not a rumour.  It's also something that could and should have been prevented.  It turns out that the API for the "Find My iPhone" app did not have protections against brute force attacks.

This, combined with the first couple hundred lines of a common password dictionary (often downloaded as the filename  "500 worst passwords") resulted in some targeted accounts being compromised.  And of course once an account password is successfully guessed, all iCloud data for that account is available to the attackers.  So no rocket science, no uber hacking skills.  Just one exposed attack surface, basic coding skills and some persistence.

Having gone through that password file, you really wonder how much folks using any of those passwords valued their data in the first place.

Apple quickly fixed the vulnerability, so it is no longer in play (unless your account was compromised prior to the mitigation and you haven't changed your password).  The code is on github if you are interested.

This just reinforces the common theme that - to put it mildly - trusting personal data to simple passwords is not recommended.  If you can't use complex passwords (for me, that's greater than 15 characters) or don't have a second factor, then don't use the service.

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

(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 2nd 2014 http://isc.sans.edu/podcastdetail.html?id=4129, (Tue, Sep 2nd)

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

Dodging Browser Zero Days - Changing your Org's Default Browser Centrally, (Mon, Sep 1st)

Mon, 09/01/2014 - 09:09

In a recent story about "what's a sysadmin to do?", we suggested that since our browsers seem to take turns with zero days lately, that system administrator should have processes in place to prepare for when their corporate standard browser has a major vulnerability that doesn't yet have a patch.  Administrators should be able to "push" out a change for their user community's default browser within a few minutes of a zero day being confirmed.

So - How exactly would you do this in an Active Directory Domain?

First of all, have a desktop or start menu shortcut that uses http:// or https:// - usually pointed to one or more corporate applications.  It's not uncommon to also see corporate web apps in the start menu.   Be sure that none of these links point to the programs themselves, just the URI's.  This gets folks in the habit of punching that shortcut every morning (or or having it auto-start for them), starting them off on the right foot - with the browser you've selected for them.  Having people start their browser by the actual link to the executable defeats the purpose of setting the defaults.

It turns out that the default browser can be changed by updating just 5 registry keys - the prefered application for htm and html files, as well as the prefered application for the ftp, http and https protocols.

 

============ Registry keys for Firefox  - reg-ff.reg ==============

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.htm\UserChoice]
"Progid"="FirefoxHTML"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.html\UserChoice]
"Progid"="FirefoxHTML"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\ftp\UserChoice]
"Progid"="FirefoxURL"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice]
"Progid"="FirefoxURL"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice]
"Progid"="FirefoxURL"


============  Registry keys for Internet Explorer - reg-ie.reg ==============

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.htm\UserChoice]
"Progid"="IE.AssocFile.HTM"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.html\UserChoice]
"Progid"="IE.AssocFile.HTM"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\ftp\UserChoice]
"Progid"="IE.FTP"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice]
"Progid"="IE.HTTP"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice]
"Progid"="IE.HTTPS"

============  Registry keys for Chrome - reg-goo.reg ==============

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.htm\UserChoice]
"Progid"="ChromeHTML"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.html\UserChoice]
"Progid"="ChromeHTML"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\ftp\UserChoice]
"Progid"="ChromeHTML"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice]
"Progid"="ChromeHTML"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice]
"Progid"="ChromeHTML"

===================================================

You can dig and find lots of other registry keys that will influence the browser, but these 5 will nail most things in a hurry - which is the goal.  You can also find more reg keys that will change the default browser, but these are the keys set by control panel (in Windows 7 anyway), so for me they're likely the safest keys - the ones that, for today at least, will be most likely to work most reliably for most environments.

So, what's the easiest way to push these settings out?   There are a few ways to go.  First, save the above into 3 different text based REG files

The easiest way in my book is to update everyone's startup - in a Group Policy, add the following to User Configuration / Windows Settings / Scripts (Logon/Logoff)

registry /s browser-chrome.reg  (or whichever REG is your target).

The trick then is to get folks to logout and login - hopefully you are forcing folks to logout each day by setting a hard logout time (a good thing to consider if you're not doing that today), so if you get your change in before folks typically start, they'll get your update.

If you need to push this out with GPO in mid-stream, you can set registry keys directly in Group Policy, under GPO > User Configuration > Preferences > Windows Settings > Registry

Microsoft publishes a "right way" to set the default browser on a few different pages, but it typically involves importing settings from a known correct station ( http://social.technet.microsoft.com/Forums/windowsserver/en-US/e63fe81b-1ad8-4303-ad1d-e2f6e3d8cb0a/default-browser-via-group-policy ).  This can be a problem if you've got multiple operating systems or want a more script-controlled approach.

There are certainly many other ways to push settings out using Group Policy (using ADM/ADMX files for instance), or by scripting using sysinternals or powershell commands.  The sysinternals approach has a lot of appeal because many admins already have a sysinternals "go fix it" approach already in their toolbelt.  Powershell appeals because it's the whiz-bang-shiny new tool, but lots of admins are still learning this language, so it might not fall into the "get it done quick" bucket so neatly.  ADMs will absolutely do the job nicely - I didn't have the time to cobble together and ADM or ADMX file for this, but will give it a shot over the next few days (unless one of our readers beats me to it that is!)

Once set, each browser can be configured using group policy using a vendor-supplied or open-source ADM or ADMX file.  Import the vendor file ADM(X) into GPO, and you'll be able to configure or restrict 3rd party browsers just as easily as you do IE.

This article was meant more as set of a "quick and dirty" ways to make this change for a large number of your user community in a hurry.  If you've got a neat script or an ADM file that does this job in a more elegant way than I've described, please, share using our comment form!

 

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

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

1900/UDP (SSDP) Scanning and DDOS, (Sun, Aug 31st)

Sun, 08/31/2014 - 07:50

Over the last few weeks we have detected a significant increase in both scanning for 1900/UDP and a huge increase of 1900/UDP being used for amplified reflective DDOS attacks.  1900/UDP is the Simple Service Discovery Protocol (SSDP) which is a part of Universal Plug and Play (UPnP). The limited information available to me indicates that the majority of the devices that are being used in these DDOS attacks are DLink routers, and some other devices, most likely unpatched or unpatchable and vulnerable to the UPnP flaws announced by HD Moore in January of 2013.

In the corresponding interval we have also seen a significant decrease in Network Time Protocol (NTP) based DDOS.  The big question in my mind is why have the attackers decided to switch from NTP, which has a maximum amplification factor of 600 plus, to SSDP which has an amplification factor of approximately 30.

If anybody has any more information on this, or even better yet, packet captures from one of the devices being used as a reflector, please let me know!

-- Rick Wanner - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

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