Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: green
Updated: 49 min 45 sec ago

ISC StormCast for Wednesday, October 8th 2014 http://isc.sans.edu/podcastdetail.html?id=4183, (Wed, Oct 8th)

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

CSAM: Scary ports and firewall remote administration, (Tue, Oct 7th)

Tue, 10/07/2014 - 13:46

Have you ever done a quick vulnerability check only to discover that someone found that vulnerability before you did and already had the system compromised?

During the early stages of a vulnerability scan, nmap is your friend just to quickly confirm what you got. In this case, the big surprise was that the firewall responded on port 4444. Anybody whoever dabbled with pentestingmay be familiar with this port: Metasploit uses port 4444 by default for its remote shell. Other then that, it is typically not used by any well known service.

At this point, with a possible compromised network firewall, there isnt much point in going much further. A quick connect with netcat oddly enough let to an HTTP error. Upon further investigation, it tuns out thatSophosfirewalls use port 4444 for https remote administration. Typically, ports like 8000,8080 or 8443are used, but then again, maybe Sophos wanted to hide their port, or just be different.

---
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

Belkin Router Apocalypse: heartbeat.belkin.com outage taking routers down, (Tue, Oct 7th)

Tue, 10/07/2014 - 13:30

According ot various reports, many users of Belkin routers are havingproblems connecting to the internet as of last night. It appears that the router will occasionally ping">heartbeat.belkin.com to detect network connectivity, but the heartbeat host is not reachable for some (all?) users. Currently, the host responds to ICMP">As a workaround, you can add an entry to the routers host file pointing heartbeat.belkin.com to 127.0.0.1. This appears to remove the block. The block only affects the DNS server on the device. It will route just fine. You can still get hosts on your network to work as long as you set a DNS server manually, for example using Googles DNS server at 8.8.8.8. .

For a statement from Belkin, seehttps://belkininternationalinc.statuspage.io

In a tweet, Belkin also pointed to this page on its community forum:http://community.belkin.com/t5/Wireless/Belkin-Routers-Internet-Outage/m-p/5796#M1466

---
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

Confusion over SSL and 1024 bit keys, (Tue, Oct 7th)

Tue, 10/07/2014 - 04:35

Yesterday and today, a post on reddit.org caused quite a bit of uncertainty about the security of 1024 bit RSA keys if used with OpenSSL. The past referred to a presentation given at a cryptography conference, stating that 1024 Bit SSL keys can be factored with moderate resources (20 minutes on a Laptop). It was suggested that this is at least in part due to a bug in OpenSSL, which according to the post doesnt pick the random keys from the entire space available.

It looks more and more like the assertions made in the presentation are not true, or at least not as wide spread as claimed.

However, this doesnt mean you should go back to using 1024 bit keys. 1024 bit keys are considered weak, and it is estimated that 1024 keys will be broken easily in the near future due to advances in computer technology, even if no major weakness in the RSA algorithm or its implementation are found. NIST recommended phasing out 1024 bit keys at the end of last year.

So what should you do?

- Stop creating new 1024 bit RSA keys. Browsers will start to consider them invalid and many other software components already do so or will soon follow the browsers lead (I dont think any major CA will sign 1024 bit keys at this point)
- Inventory existing 1024 bit keys that you have, and consider replacing them.

There may be some holdouts. Embedded systems (again) sometimes cant create keys larger then 1024 bits. In this case, you may need to look into other controls.

With cryptograph in general, use the largest key size you can afford, for SSL, your options for RSA keys are typically 2048 and 4096 bits. If you can, got with 4096 bits.

[1]https://www.reddit.com/r/crypto/comments/2i9qke/openssl_bug_allows_rsa_1024_key_factorization_in/

---
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 Tuesday, October 7th 2014 http://isc.sans.edu/podcastdetail.html?id=4181, (Tue, Oct 7th)

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

CSAM: Patch and get pw0ned (not OR)., (Mon, Oct 6th)

Mon, 10/06/2014 - 11:55

"Patch as fast as you can" appears to be yet another common security practice leading to network doom. Bricked machines can't be hacked easily, so this may help a bit with "security". But then again, how insecure do you want your machines to be in order to support the latest and greatest patching tools.

Nice story from Lyalc:

"Some years ago, vulnerability scanning a production environment for the first time found about half of the critical production servers in this payment environment had the Windows File protection feature disabled via a registry key."

Ok. This would get me a bit scarred too. Windows File Protection (WFP) is a great feature to keep those Win2k and 2k3 systems a bit more secure, and make hacking them hard enough that some script kiddies may not bother. I like it, and wouldn't want it to be disabled all for sudden.

"Needless to say, incident response processes kicked in very quickly. ?During initial analysis, it was observed that the affected servers had ?patches applied to a critical payment component, several weeks prior to the vulnerability scanning. ?This software, from a global vendor of payment products, is used by a large portion of the payment industry, making it a natural target for malware and rootkit purveyors."

Ok. this would get me excited too (and excitement is never good in security. I like my security operations to be boring...). Payment systems, I think I heard of a couple cases where they got attacked. Yes, they appear to be patched. But what patch? How long were they vulnerable before the patch was applied? And well, defense in depth is for people who can't do incidents response as Lyalc?coninues:

...the site did not have FIM installed, nor had vulnerability scanning been undertaken previously. [FIM: Forefront Identity Manager]

So what happened? How can this possibly be a false positive?

Following this line of investigation identified that the patch package installer was disabling WFP, but neglecting to re-enable the feature, leaving the servers vulnerable to modifications of system files.

Ah! The patch system.?

Just a word about patches, in a week where we just got done with a good number of highly critical emergency patches for shellshock: Stop worrying about speed alone. You will lose. Think about shellshock and heartbleed: You can't possibly patch an enterprise fast enough. What you need instead is:

  • a well thought out patching process. How are we patching, how are we avoiding down systems, how do we make sure the patch got actually applied?
  • a comprehensive inventory. You can't secure (or patch) what you don't have
  • solid controls to detect attacks and exploited systems. You need network visibility to be able to detect attacks and more importantly, exploited systems.

?

---
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

Shellshock: More details released about CVE-2014-6277 and CVE-2014-6278. Also: Does Windows have a shellshock problem?, (Mon, Oct 6th)

Mon, 10/06/2014 - 09:12

Michal Zalewski did publish more details about the two vulnerability he discovered in the aftermath of Shellshock. He used a fuzzer to discover both vulnerabilities, and now published PoC exploits for both. [1]

To check if you are vulnerable, Michal points to this test string:

foo='() { echo not patched; }' bash -c foo

A quick test shows up-to date OS X, CentOS and Ubuntu as not vulnerable.

The first one, CVE-2014-6277, is a more "traditional" use of uninitialized memory. In most cases, this will just cause a crash. However, it can also be exploited to achieve arbitrary code execution. At its core, this is again due to how functions are parsed in environment variables, so this would be exploitable via HTTP requests.

The second one, CVE-2014-6278, is closer to the original shellshock bug. The PoC exploit posted by Michal is:

HTTP_COOKIE='() { _; } >_[$($())] {echo hi mom; id;}' bash -c :

Just like the first bug, the parser is confused as to where the function definition ends, and it executes the code in { }.

Late last week, a blog post about a similar flaw in Windows suggested to some that the Windows shell is vulnerable as well [2]. The vulnerability is however slightly different. It is not passed to other shells spawned from the original one. Also, in Windows, it is even less likely then in Unix to have cgi-bin scripts call a shell directly. The only realistic exploit vector in Windows remain environments like cygwin that install bash on Windows.

[1] http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html
[2] http://thesecurityfactory.be/command-injection-windows.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

Spoofed packets with Window Size 6667: Anybody else seeing this?, (Mon, Oct 6th)

Mon, 10/06/2014 - 07:26

Thanks to Tim for providing some packet captures. Anybody else seeing "weird" TCP packets? In particular we are interested if you see them OUTBOUND. We are looking for the likely broken tool that may generate these packets.

Some of the packet properties:

  • Packet size of 60 bytes (IP Headers + TCP)
  • Protocol is always TCP
  • various TOS values
  • various (random?) IP IDs. But repeating for same source IP
  • various TTLs (possible that packets from different IPs actually originate from different host)
  • DF flag is set
  • some source IPs are clearly "odd", e.g. multicast?source IPs like 255.127.0.0
  • TCP source and dest port is 0
  • Sequence numbers sometimes repeat even if source IPs change (argument for likely spoofed sources)
  • overall malformed TCP headers (e.g. header size < 20, various bad flag combinations).
  • Window size of 6667 (maybe this was supposed to be the source or dest. port?)
  • The packets arrive at relatively high rate (couple packets/sec with breaks... )

Quick tshark?output?of a sample with obfuscated target IP:

85.133.23.50 -> x.y.z.14 TCP 74 [TCP Retransmission] 0?0 [SYN, RST, ACK, URG, ECN, CWR, NS, Reserved] Seq=0 Ack=1 Win=6667 Urg=0 Len=0
85.133.23.50 -> x.y.z.14 TCP 74 [TCP Retransmission] 0?0 [SYN, RST, ACK, URG, ECN, CWR, NS, Reserved] Seq=0 Ack=1 Win=6667 Urg=0 Len=0
192.99.37.41 -> x.y.z.119 TCP 74 [TCP Retransmission] 0?0 [FIN, SYN, RST, PSH, URG, CWR, NS, Reserved] Seq=0 Win=6667 Urg=0 Len=16
192.99.37.41 -> x.y.z.119 TCP 74 [TCP Retransmission] 0?0 [FIN, SYN, RST, PSH, URG, CWR, NS, Reserved] Seq=0 Win=6667 Urg=0 Len=16
192.99.37.41 -> x.y.z.119 TCP 74 [TCP Retransmission] 0?0 [FIN, SYN, RST, PSH, URG, CWR, NS, Reserved] Seq=0 Win=6667 Urg=0 Len=16
192.99.37.41 -> x.y.z.119 TCP 74 [TCP Retransmission] 0?0 [FIN, SYN, RST, PSH, URG, CWR, NS, Reserved] Seq=0 Win=6667 Urg=0 Len=16
192.95.30.185 -> x.y.z.24 TCP 74 0?0 [FIN, PSH, ACK, URG, ECN, Reserved] Seq=1 Ack=1 Win=6667, bogus TCP header length (0, must be at least 20)
137.118.96.23 -> x.y.z.70 TCP 74 0?0 [FIN, SYN, RST, PSH, URG, ECN, CWR, NS, Reserved] Seq=0 Win=6667, bogus TCP header length (12, must be at least 20)

Internet Protocol Version 4, Src: 137.118.96.23 (137.118.96.23), Dst: x.y.z.70 (x.y.z.70)
Version: 4
Header Length: 20 bytes
Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 60
Identification: 0xa2c7 (41671)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 49
Protocol: TCP (6)
Header checksum: 0x0cde [validation disabled]
[Good: False]
[Bad: False]
Source: 137.118.96.23 (137.118.96.23)
Destination: x.y.z.70
Transmission Control Protocol, Src Port: 0 (0), Dst Port: 0 (0), Seq: 0
Source Port: 0 (0)
Destination Port: 0 (0)
[Stream index: 872]
[TCP Segment Len: 28]
Sequence number: 0?(relative sequence number)
Header Length: 12 bytes (bogus, must be at least 20)

09:16:46.687528 IP 137.118.96.23.0 > x.y.z.70.0: tcp 28 [bad hdr length 12 - too short, < 20]
0x0000: 4510 003c a2c7 4000 3106 0cde 8976 6017 E..<..@.1....v`.
0x0010: xxyy zz46 0000 0000 c0f1 59ce 0000 0000 .3.F......Y.....
0x0020: 3bef 1a0b ff7f 0000 6cf6 2346 0000 0000 ;.......l.#F....
0x0030: 0000 0000 0000 0000 a002 7d78..........}x

---
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, October 6th 2014 http://isc.sans.edu/podcastdetail.html?id=4179, (Mon, Oct 6th)

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

Detecting irregular programs and services installed in your network, (Sun, Oct 5th)

Sun, 10/05/2014 - 09:34

When the corporate network becomes target, auditing for security policy compliance can be challenging if you don't have a software controlling irregular usage of administrator privilege granted and being used to install unauthorized software or to change configuration by installing services that could cause an interruption in network service. Examples of this possible issues are additional DHCP Servers (IPv4 and IPv6), Dropbox, Spotify or ARP scanning devices.

We can use nmap to detect all protocols that sends broadcast packets and are supported by packetdecoders.lua:

  • Ether
    • ARP requests (IPv4)
    • CDP - Cisco Discovery Protocol
    • EIGRP - Cisco Enhanced Interior Gateway Routing Protocol
    • OSPF - Open Shortest Path First
  • UDP
    • DHCP
    • Netbios
    • SSDP
    • HSRP
    • DropBox
    • Logitech SqueezeBox Discovery
    • Multicast DNS/Bonjour/ZeroConf
    • Spotify

The following example shows how to use nmap with the broadcast listener script and we can see the result of a device with dropbox installed, a device sending ARP request (a router in this case) and a device sending DHCPv6 requests:

You can run this program periodically to track common security issues in your network, just in case your IPS could be missing something ;)

Manuel Humberto Santander Pelaez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

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

Testing for opened ports with firewalk technique, (Sat, Oct 4th)

Sun, 10/05/2014 - 09:33

There is an interesting way of knowing what kind of filters are placed in the gateway of a specific host. It is called firewalk and it is based on IP TTL expiration. The algorithm goes as follows:

  • The entire route is determined using any of the traceroute techniques available
  • A packet is sent with the TTL equal to the distance to the target
  • If the packet times out, it is resent with the TTL equal to the distance to the target minus one.
  • If an ICMP type 11 code 0 (Time-to-Live exceeded) is received, the packet was forwarded and so the port is not blocked.
  • If no response is received, the port is blocked on the gateway.

Let?s see this with a real example. Consider the following network diagram:

Firewalking happens with the following steps:

  1. Traceroute packets are sent to determine the gateway with decremental TTL:

....

2. An ICMP Time Exceeded message is received from the default gateway for the TTL=2 and TTL=1 packet, which means there are two gateways between origin and destination and TTL=3 is the distance to the destination

3. Several packets are sent with TTL=3 to the destination varying the destination port. The sequence goes as follows: A first packet is sent with TTL=3. If a timeout occurs, a second packet is sent with TTL=1. If an ICMP type 11 code 0 (Time-to-live exceeded) is received, the gateway is forwarding the packet.

Let?s see the first packet to port 1 and TTL=3:

Timeout occurs, so same packet is sent with TTL=2:

ICMP type 11 code 0 is sent from the gateway routing the destination host, which means the packet was forwarded and the port is opened:

How can we use this technique? Nmap has a firewalk script that can be used. For this example, the following command should be issued:

nmap --script=firewalk --traceroute 172.16.2.165

Manuel Humberto Santander Pelaez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

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

CSAM: The Power of Virustotal to Turn Harmless Binaries Malicious, (Fri, Oct 3rd)

Fri, 10/03/2014 - 10:47

We all know that anti virus, the necessary evil of basic computer security, isn't a stranger to false positives. So no big surprise here when John is writing that he ran into such a false positive during an incident response:

I was scanning a forensic drive image with clamav and scored a positive hit on a file.

Great. ClamAV, a free anti-virus product. Of course, we don't trust it. So John did what most of use would have done, and submitted the suspect binary to Virustotal:

Virustotal showed 14 out of other 50 AV vendors' products thought it was malware as well.

Ouch! 14 out of 50? Many actual malware samples I submit get a lower rate then that. Turns out the binary in question was a desktop management software, "lunchwrapper.exe", and the AV tools picked up on it's file download component (the famous "generic downloader" signatures).

But you think this is bad? Listen what happened next according to John:

The scary part was that after I submitted the sample, other major AV vendors decided that the submitted sample was malicious and our endpoint software starting quarantining the program after the AV dats had updated.

After all, as my fellow developer can attest?too: The reason we allow people to use our applications is so that we don't have to do any testing ourselves.

(BTW: Virustotal/Google are doing great work, and I think it is a good thing that they are distributing samples. The problem is how AV vendors use this information.)

---
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, October 3rd 2014 http://isc.sans.edu/podcastdetail.html?id=4177, (Fri, Oct 3rd)

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

Why is your Mac all for sudden using Bing as a search engine?, (Thu, Oct 2nd)

Thu, 10/02/2014 - 13:14

Even as a Mac user, you may have heard about Bing, at least you may have seen it demonstrated in commercials [1]. But if your default search engine on your Mac is all for sudden switched to Bing, this may be due to another piece of legacy software that some Mac users may have a hard time living without : Microsoft's Internet Explorer. So why not just search ("google") if there is a version for OSX:

In short: I don't think this software does anything illegal. It clearly advertises what it does. If you feel otherwise, you can file a complaint with courts in Cyprus where the company is located.

[1] https://www.youtube.com/user/bing
​[2] http://info.trovi.com/Privacy

---
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

CSAM: My Storage Array SSHs Outbound!, (Thu, Oct 2nd)

Thu, 10/02/2014 - 06:29

Kuddos to Matthew for paying attention to egress traffic. We keep emphasizing how important it is to make sure no systems talk "outbound" without permission. Just this last week, various Shellshock exploits did just that: Turn devices into IRC clients or downloading additional tools via HTTP, or just reporting success via a simple ping.

So no surprise that Matthew wrote us: "... the first time I saw the storage array SSH to the internet I about fainted. ..."

I would be surprised too! And turns out that isn't the only person that experienced this. Mark noted:

"Had the seem freak moment when I saw it happen.  The SAN happily communicating to an outside entity.  Though the company had been well and truly hosed."

Luckily, before going too far down the incident handling road, Matthew realized that this was a false positive. The storage array in question called "back home" to the vendor to report on its status. The purpose of this communication is to report failed disks or other critical events that may trigger a service call. Vendors will agree to turn off this feature, but then of course it is up to you to recognize faulty disks.

Got anything like that? Let us know. (if possible with log snippet / packet capture or other show-and-tells)

---
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

Cyber Security Awareness Month 2014: Scary False Positives, (Thu, Oct 2nd)

Thu, 10/02/2014 - 05:57

To "celebrate" cyber security awareness month, we decided to focus on "scary false positives" during October. If you have any to share, please let us know. What we are looking for is preferably a lot entry, or another "indicator" that led you to believe that your system was compromised, but in the end turned out to be a false positive.

Please e-mail your stories to handlers-at-isc.sans.edu or use out Contact form.

---
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 Thursday, October 2nd 2014 http://isc.sans.edu/podcastdetail.html?id=4173, (Thu, Oct 2nd)

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

Xen Security Advisory - XSA 108 - http://xenbits.xen.org/xsa/advisory-108.html, (Wed, Oct 1st)

Wed, 10/01/2014 - 15:04

Xen has issued an advisory and a related patch to address an issue that allows a "buggy or malicious HVM guest to crash the host or read data relating to other guests or the hypervisor itself."

Xen 4.1 and onward are vulnerable, only x86 systems are vulnerable. ARM systems are not vulnerable.

Applying the patch resolves this issue.

Russ McRee | @holisticinfosec

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

Security Onion news: Updated ShellShock detection scripts for Bro, (Wed, Oct 1st)

Wed, 10/01/2014 - 13:03

Per Security Onion's Doug Burks, Seth Hall has developed some comprehensive ShellShock detection scripts for Bro.
These scripts "detect successful exploitation of the Bash vulnerability with CVE-2014-6271 nicknamed "ShellShock" and are more comprehensive than most detections in that they're watching for behavior from the attacked host that might indicate successful compromise or actual vulnerability."
Seth has updated these scripts again today to "Add shellscripts as a post-exploit detection mechanism."
Doug has updated the securityonion-bro-scripts package to include these changes and has also updated the securityonion-web-page package to include some ELSA queries for "ShellShock Exploits" and "ShellShock Scanners".

This is great for current Security Onion users, and even better for readers who have not yet investigated and invested in Security Onion. Now's the time to become familiar and improve your situational awareness, particularly given the fact that it's National Cyber Security Awareness Month. :-)

Everything you need is available on Doug's blog: http://blog.securityonion.net/2014/10/new-securityonion-bro-scripts-and.html

Russ McRee | @holisticinfosec

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

VMware security advisory: VMSA-2014-0010 http://www.vmware.com/security/advisories/VMSA-2014-0010.html, (Wed, Oct 1st)

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