Finally we got an official announcement. For all the details, jump straight to the original announcement . Below see the TL;DR; version:
The problem is limited to SSLv3. SSLv3 is often considered similar to TLSv1.0, but the two protocols are different.
SSLv3 had issues in the past. Remember the BEAST attack? It was never resolved (other then moving to TLS 1.1/2). The only alternative was to use a stream cipher like RC4, which had its own problems.
But this POODLE issue is different. With block ciphers, we have a second problem: What if the block to be encrypted is too short? In this case, padding is used to make up for the missing data. Since the padding isnt really considered part of the message, it is not covered by the MAC (message authorization code) that verified message integrity.
So what does this mean in real live? The impact is similar to the BEAST attack. An attacker may either play MitM, or may be able to decrypt parts of a message if the attacker is able to inject data into the connection just like in the BEAST attack. The attack allows one to decrypt one byte at a time, if the attacker is able to inject messages right after that byte that include only padding.
What should you do: Disable SSLv3. There is no patch for this. SSLv3 has reached the end of its useful life and should be retired.
This isnt a patch now. Give it some time, test it carefully, but get going with it. The other problem is that this is a client and a server issue. You need to disable SSLv3 on either. Start with the servers for highest impact, but then see what you can do about clients.
The other option to fix this problem is to use SSL implementations that take advantage of the TLS_FALLBACK_SCSV feature. This feature notifies the other side that you first tried the stronger cipher. This way, they can reject the downgrade attempt that may have been introduced by a MitM attack. But it isnt clear which implementations use this feature at this point, and which dont. A patch for OpenSSL 1.0.1 was released earlier today implementing TLS_FALLBACK_SCSV
To test if your server is vulnerable: Use https://ssltest.com
To test if your client is vulnerable: We setup a test page at https://www.poodletest.com">
To turn off SSLv3 support in Internet Explorer 11: Setting - Internet Options - Advanced Tab - Uncheck SSLv3 under Security. ">https://www.openssl.org/~bodo/ssl-poodle.pdf
To turn off SSLv3 support in Internet Explorer 11:
Setting - Internet Options - Advanced Tab - Uncheck SSLv3 under Security.
Oracle have released itscritical patch update for October 2014, this series of patches will provide fixes for 154 vulnerabilities across a number of product families including: Oracle Database, Oracle Fusion Middleware, Oracle Enterprise Manager Grid Control, Oracle E-Business Suite, Oracle Supply Chain Product Suite, Oracle PeopleSoft Enterprise, Oracle JDEdwards EnterpriseOne, Oracle Communications Industry Suite, Oracle Retail Industry Suite, Oracle Health Sciences Industry Suite, Oracle Primavera, Oracle Java SE, Oracle and Sun Systems Product Suite, Oracle Linux and Virtualization, and Oracle MySQL.
For more details please refer to the following link:
ISC StormCast for Wednesday, October 15th 2014 http://isc.sans.edu/podcastdetail.html?id=4193, (Wed, Oct 15th)
Yesterday, a number of news sites published speculative reports about a possible OpenSSLbug to be fixed today. According to these reports, the bug affects SSL 3, and is critical. Can-)
Initially, it looked like an OpenBSD patch lead to an answer, but turns out the patch was old (thx to those who wrote in and responded,in particular based on the tweet by @martijn_grooten). But instead, there are new leads now, in particular a discussion on Stackexchange . In this discussion, a comment by Thomas Pornin outlines how padding in SSLv3 can lead to MitM attacks. This would be an outright attack against the SSLv3 protocol, and less against a specificimplementation. It would affect clients as well as servers.
We will update this post as we learn more. At this point: Dont panic and wait for a patch from your respective vendor. We are not aware of any active exploitation of this problem, but please let us know if you see any evidence of that happening.
If you choose to disable SSLv3 on a server, but leave TLS 1.0 enabled, Windows XP with IE 6 will no longer be able to connect (but older versions of IE will be able to connect from Windows XP machines).
How can you test if a server supports SSLv3? Either use ssllabs.com, or using the openssl client: (if it connects, it supports SSLv3)
openssl s_client -ssl3 -connect [your web server]:443
How can I check if my browser can live without SSLv3? If you can read this, then you support TLSv1 or higher. I turned off SSLv3 support on this site for now. But pretty much all browsers support SSLv3.
You tell us not to panic, but you turned of SSLv3? Yes. I wanted to see what happens if I turn off SSLv3. So far, the only issue I found was Windows XP with IE 6, a configuration I probably dont want to support anyway.
Microsoft only published 8 instead of the promised 9 bulletins. Also, of particular interest is MS14-060 which was pre-announced by iSight Partners. iSighthas seen this vulnerability exploited in some APT style attacks against NATO/US military interests and attributes these attacks to Russia. Attacks like this have happened with many Office vulnerabilities in the past, but it is unusual for a company to announce the respective attacks and CVE numbers ahead of Microsofts bulletin release. Note that we got a total of 3 already exploited vulnerabilities in this months release. Don">MS14-059
Vulnerability in ASP.NET MVC Could Allow Security Feature Bypass
Microsoft Developer Tools
CVE-2014-4075 KB 2990942
exploited.">MS14-060 Vulnerability in Windows OLE Could Allow Remote Code Execution(replaces">MS14-061 Vulnerability in Microsoft Word and Office Web Apps Could Allow Remote Code Execution">MS14-063 Vulnerability in FAT32 Disk Partition Driver Could Allow Elevation of Privilege">Critical: Anything that needs little to become interesting">Less Urt practices for servers such as not using outlook, MSIE, word etc. to do traditional office or lei\ sure work.
Adobe published two security bulletins today:
APSB-22 : fixes 3 vulnerabilities in Adobe Flash Player as well as in Adobe Air. The vulnerabilities are rated with a priority of 1 for Flash Playerrunning onWindows and OS X , which means they have already been exploited in targeted attacks.
APSB-23  : another 3 vulnerabilities, but this time in Cold Fusion. The priority for these updates is 2which indicates that they have not yet been exploited in the wild.
ISC StormCast for Tuesday, October 14th 2014 http://isc.sans.edu/podcastdetail.html?id=4191, (Tue, Oct 14th)
[This is a guest diary published on behalf of Chris Sanders]
Hunting for evil in network traffic depends on the analysts ability to locate patterns and variances in oceans of data. This can be an overwhelming tasks and relies on fundamental knowledge of what is considered normal on your network as well as your experienced-based intuition. These dark waters are navigated by finding glimmers of light">and following them where they lead you by carefully investigating all of the data sources and intelligence in your reach. While hunting the adversary in this manner can yield treasure, following some of these distant lights can also land you in the rocks.
One scenario that often puts analysts in murky waters occurs when they chase patterns of network traffic occurring over clearly visible intervals. This periodic activity often gets associated with beaconing, where analysts perceive the timing of the communication to mean that it may be the result of malicious code installed on a friendly system.
As an example, consider the flow records shown here:
Figure 1 (click on image for full size)
If you look at the timestamps for each of these records, you will see that each communication sequence occurs almost exactly one minute from the previous. Along with this, the other characteristics of the communication appear to be similar. A consistent amount of data is being transferred from an internal host 172.16.16.137 to an external host 220.127.116.11 each time.
So, whats going on here? Less experienced analysts might jump to the conclusion that the friendly device is compromised and that it is beaconing back out to some sort of attacker controlled command and control infrastructure. In reality, it doesn" />
Figure 2 (click on image for full size)
As analysts, we are taught to identify patterns and hone in on those as potential signs of compromise. While this isnt an entirely faulty concept, it should also be used with discretion. With dynamic content so prevalent on the modern Internet, it is incredibly common to encounter scenarios where devices communicate in a periodic nature. This includes platforms such as web-based e-mail clients, social networking websites, chat clients, and more.
Ultimately, all network traffic is good unless you can prove its bad. If you do need to dig in further in scenarios like this, try to make the best use of your time by looking for information you can use to immediately eliminate the potential that the traffic is malicious. This might include some basic research about the potentially hostile host like we did here, immediately pivoting to full PCAP data to view the content of the traffic when possible, or by simply examining the friendly host to determine which process is responsible for the connection(s). The ability to be selective of what you choose to investigate and to quickly eliminate likely false positives is the sign of a mature analyst. The next time you are hunting through data looking for evil, be wary when your eyes are drawn towards beaconing">Blogs:">">http://www.chrissanders.org(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
I had an interesting discussion tonight with fellow handler Manuel on the pros and cons on port security as it relates to Network Access Control. I thought it would be interesting to see where others in the security field stand on the issue. Is it worth the effort or not? Is it a valuable tool in Defense in Depth? Here are some of the For and Against arguments we discussed:
- Stops others from being able to plug into your infrastructure, they would have to search to find a port that has not been configured correctly
- Can audit logs to determine if empty ports are turned on or off
- Can alert you more quickly to rogue devices being plugged into your infrastructure
- Not a perfect solution but should be part of your defense in depth solution, its not meant to be a stand alone solution
- If you fake the MAC address to the host, you are in
- Insider/outsider threat is great since physical security to equipment is not well controlled in many organizations
- Have to take into account failover scenarios or you can DoS yourself
- Hard to manage large number of switch ports to ensure they are configured correctly at all times
So, is port security worth the effort or do many of you find its too time consuming and the benefits are not that great? If you using it and have tips for successful implementation, please share them so others can benefit. It is Cyber Security Awareness Month and this would be a good opportunity to help educate each other on issues you have encountered with port security or how it has helped protect your organization.(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC StormCast for Monday, October 13th 2014 http://isc.sans.edu/podcastdetail.html?id=4189, (Sun, Oct 12th)
With all the high profile breaches pretty much every one of us has received a breach notification email in the recent past. But how many of you could tell if it was legitimate?
Take this email from Target from early in 2014.">With all the Target Phishing ">around at the time many people questioned the legitimacy of this email.At first glance it looks pretty legitimate.
With all the garbage email we receivemost of us have been diliigent that at a minimum we check two things:
- links in the email point to where the link says it points and that where the linkpointslooks legitimate,
- sender address, and reply-to, addressdoes not look spoofed
In this case there is only one link in the email and it points to creditmonitoring.target.com, which is a page in the target.com website. What made people question the legitimacy was the from email address. It was sent from TargetNews@target.bfio.com. Clearly not a Target domain.
It turns out this email is legitimate. bfi0.com is a part of Epsilon Interactive a marketingservice that Target uses for customer marketing. ">A: To make sure you continue to receive Target emails in your personal inbox (not bulk or junk folders), please take a moment to add Target.com">">This one from Fisher Pricealso looks, and is, legitimate. ">">From: "> ">">Subject: Important Request from">">Reply-To:">To ensure you receive our">">">In order to improve your">Online Store website experience, we have transitioned to a different technology platform. As part of the transition, existing password information has been removed from your account. Before you can login to your account on the new site, you will need to reset your password using the Forgot Password?">Thank you for your immediate attention to this matter and your continued interest in">">">Please note that this does not affect your password for">.com. No changes are needed for your">Questions? Please contact Customer Service at">">">">">As far as I know this email did not have anything to do with a breach, just anupgrading of their website security, butChris, who sent this to the ISC, indicated that it stank of Phishing. I must admit that something about this emailgave me the heebee jeebees at first, but at second glance this isone of the better ways of getting users to change credentials. There are no links in the email only a recommendation to use the websites Forgot Password">">What">
-- 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.
Microsoft have announced the heads-up for this month security patches. With nine bulletins three are rated as critical, one as moderate and five as important.
ISC StormCast for Friday, October 10th 2014 http://isc.sans.edu/podcastdetail.html?id=4187, (Fri, Oct 10th)
Hassan submitted this story:
While reviewing our IDS logs, we noticed an alert for IRC botnet traffic coming from multiple servers in a specific VLAN.
Ouch! One thing I keep saying in our IDS Class: If your servers all for sudden start joining IRC channels, then they are either very bored, or very compromised. But lets see how it went for Hassan. Hassan had what every analyst wants: pcaps! So he looked at the full packet capture of the traffic:
The traffic wasnt 100% IRC. But it looked suspect
Further analysis showed that the traffic originated from servers that were currently in the process of being moved between hosts via vMotion. The content of the memory / disk being transferred">Using volatility we took a vaddump of the memory dump and searched the individual process dumps for the string pattern to identify the infected process.">we found out that this part of the memory belongs to the AV process :). Apparently part of its signatures expanded in the memory during the scan.
Great work Hassan! This one was a good one and yes, anti-virus patterns will often contain malicious strings and can trigger an IDS if it spots these strings in transfer. The signatures as downloaded from the vendor are often encrypted, compressed or otherwise obfuscated, so your IDS usually doesnt recognize these patterns. But once loaded into memory on the host, the signatures are in the clear.
ISC StormCast for Thursday, October 9th 2014 http://isc.sans.edu/podcastdetail.html?id=4185, (Thu, Oct 9th)
Its a note that many of us have received. If were unlucky, its a note that your (not-a-packet-expert) boss has received and weve had to explain it.">We recently received 1 complaint(s) regarding the article below. This issue appears to have originated from your domain (IP address: x.x.x.x).
Please take the appropriate action with your customer or the account in question, enforcing your Acceptable Use Policy.
Please include your original email to SOMEISP.com in any replies.
A note like this takes a fair amount of explanation when discussing it with your client (or manager), who usually isnt a packet guru. Usually the narrative goes something like this:
While (maybe) its a good thing that an ISP is looking at traffic to find malicious patterns, unfortunately, in this case the ISP just plain gets it wrong. Their entire conclusion is based on the source port. Unfortuntately, the source port in most TCP communications is what is called an ephemeral port - its either the next free port available after 1024, or a random free port above 1024.
Add to that, in outbound communications, most TCP sessions are run through a firewall that NAT each session ( NAT = Network Address Translation), so that each of these ephemeral ports is mapped to yet a different ephemeral port.
As you can see, from the outside networks perspective, the source port could be just about anything. So if you are looking for a suspicious port, youll find it as a source port on any corporate firewall most days.
OK, so should the abuse@ folks look at the port at the other end? Umm- sort-of. Say someone is sending you an email or browsing to your website - in this case, the ephemeral port is at their end, and the target port is at your end.
Really, what you want to do is look at the ports at both ends - but not to make a final determination. You might use that method to narrow down your search, before you then look at the contents of the actual packets. An even better approach is to *start* by looking at the contents of the packets - but if youre an ISP that adds up to a lot of packets which needs a corresponding amount of CPU and disk to deal with it.
If you are an organization who needs to get a handle on outbound traffic (which is just about every organization), consider implementing an IPS on the traffic to/from the inside interface of your firewall - at that location you can see the true IP addresses and ports of all traffic, both source and destination.
Another great thing to look at implementing is a Netflow collector (or sFlow or jFlow or IPFIX, depending on your gear) - a tool like this helps you to slice and dice your network traffic statistics to get quick answers, or in many shops netflow graphical display is the most used feature, allowing a quick, visual way to identify odd traffic or trends.
Also an egress filter goes a long way to containing problems - if you only allow permitted traffic and have a default deny policy for all mystery traffic, youll find that your problems are more likely to stay contained within your network, and if you are looking at your logs youll be alerted much earlier in the process.
What youll find with proper monitoring like this (IPS, Netflow, egress filtering and log monitoring) is that very likely you *do* have infected machines here and there. For instance we did the log check thing last week at a client site and found 1 station trying to infect the neighbors with shellshock. The difference between your logs and the ISPs logs though is that your logs will properly identify the problem workstation, and the alerts in your logs will be a lot less likely to be a false positive.
The sad thing that Ive found is that once you get a false positive note like this from an ISP, youre generally in for a few weeks of them before you can escalate to a support person who understands enough to know that theyre getting it wrong, and has the clout to fix the ISPs process.
Please, use our comment form to let us know if youve gotten a note like this, and if it was a false positive or not.
ISC StormCast for Wednesday, October 8th 2014 http://isc.sans.edu/podcastdetail.html?id=4183, (Wed, Oct 8th)
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.
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 18.104.22.168. .
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