Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: green
Updated: 5 min 22 sec ago

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

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