Latest Alerts

Phishing via Social Media, (Fri, Jan 24th)

Fri, 01/24/2014 - 06:07
The use of social media as an attack vector is nothing new; We’ve all seen plenty of stories in the media of fake FaceBook profiles such as the one for American Admiral James Stavridis back in 2012 [1]. This tends to mean we’re more wary of Facebook and Twitter, but many of us still use LinkedIn as it is a great tool to build out professional networks, tap in to like-minded groups or be stalked approached by recruiters.   If a LinkedIn request comes from a name you recognise, do you blindly except the request or do a bit of investigating first to validate that request? Let’s say you are the cautious, security minded type and check of the profile of the sender and it looks legitimate, I’m betting most of us would then accept the request and get on with our day.   The last couple of Diaries I’ve written have been about breaches and one of the key components of any good attack is solid reconnaissance. An adversary with a clear understanding of a company’s staff can leverage that to get a much more complete picture than any port scan or pin-point key human targets to exploit. Plenty of penetration testers [2] use social media to devastating effect and so do real adversaries.     Some of you reading this will be thinking: A) Pah! I don’t use an form of social media so I’m safe B) Meh, I’d never fall for any of that shenanigans, I’m too paranoid/security-minded C) Mu-ha-ha! I use the Lynx text only browser [3] – what is this wide wide web you speak off?   Well, how about the person next to you or head of HR or the CEO? This blog post [4] illustrates a very smart, well thought out and executed social engineering attack using LinkedIn. LinkedIn have a very responsive security team and here’s one way to alert than of bogus profiles[5] should you ever run in to one, but would most people pick up on a fake profile?   I’ll leave you with this question: How would you and your security policies counter a targeted attack like that against a senior board member?     [1] http://www.telegraph.co.uk/technology/9136029/How-spies-used-Facebook-to-steal-Nato-chiefs-details.html [2] http://pen-testing.sans.org/blog/pen-testing/2011/11/04/the-pushpin-tool-incorporating-geolocation-info-leakage-via-social-networks-in-your-pen-tests [3] http://lynx.browser.org/ [4]http://washingtonnote.com/john-bolton-reaches-email-beware/ [5]https://help.linkedin.com/app/safety/answers/detail/a_id/146  

Chris Mohan --- Internet Storm Center Handler on Duty

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

ISC StormCast for Friday, January 24th 2014 http://isc.sans.edu/podcastdetail.html?id=3800, (Fri, Jan 24th)

Thu, 01/23/2014 - 19:47
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Learning from the breaches that happens to others Part 2, (Thu, Jan 23rd)

Thu, 01/23/2014 - 04:53
My last Diary piece was on the analysis of multiple similar breaches with a great deal of technical details from an external team brought in to handle the incidents, but it didn't touch on the human elements that are intertwined with each and every breach.   Sometimes reading a technical report is the same as a stunningly obvious mystery book, it takes you two pages to work out they used an open source scanner to find a foothold and exploit it, then later they use the same default password across the entire network and finally you know the bad guy is going to zip up what they stole and send it to a drop point before ever reading the next twenty pages of the report.  When reading this part of me wants to scream "Why did no-one see any of this in the first place or do anything about it?" and "Who let this happen?".   Well to remedy that, I offer you a second breach report: The United States' Department of Energy (DoE) suffer a breach in July 2013 and here's a special report by a different department giving their assessment of the breach and DoE [1]. I take my hat off to the DoE for publishing this report and the very honest assessment of how they failed, and what they needed to do to fix the various issues uncovered.   This isn't a technical read, but so worth the time for any security person to read and understand the chain of events that lead to a breach occuring. The report issued focuses on the human elements in the breach, maps the events to a timeline and who was responsible. For me, this a fascinating glimpse of third party's blunt assessment of what failed, how it failed and why it failed with direct correlation to those that could have prevented or take action on the breach.    I'm going to leave it up to you to draw any conclusions from the paper as a security person, incident responder or as an IR manager*, but suggest this would be a good paper to summarise and give to whoever is in charge of security to understand the internal human elements that aided the breach.   Why? My suggestion would be to understand the pain points incident response teams can facing being alerted to an incident in a timely manner.    Again, if you know of any other papers you believe IR teams should have to read on the details of a breach , add them in the comments or send them in to us [2]   [1] http://energy.gov/sites/prod/files/2013/12/f5/IG-0900.pdf   * Shameless plug for a great SANS class for incident response managers https://www.sans.org/course/incident-response-team-management   [2] https://isc.sans.edu/contact.html#contact-form

 

Chris Mohan --- Internet Storm Center Handler on Duty

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

ISC StormCast for Thursday, January 23rd 2014 http://isc.sans.edu/podcastdetail.html?id=3797, (Thu, Jan 23rd)

Wed, 01/22/2014 - 20:36
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

iTunes 11.1.4 is now available - addressing numerous CVEs, (Wed, Jan 22nd)

Wed, 01/22/2014 - 14:45

Chris Mohan --- Internet Storm Center Handler on Duty

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

Learning from the breaches that happens to others, (Wed, Jan 22nd)

Wed, 01/22/2014 - 01:51
Initially when major breaches or incidents announced via the media, everyone and their pet dog has a theory about how it happened.  As an Incident handler, I love a good explanation of what really happened when systems get breached, rather that the wide ranging, speculative theories. Most of us completely understand that during a breach information has to be limited to a need to know basis while the incident is being worked on and have to run their course before the investigators can even think about publically publishing their findings. That means the armchair security experts can pontificate endlessly of what they think happened. When an official report does get published of the breach, I tend to feel big chunks are missing, with some excellent notable exceptions.  When discovering a public, well written, comprehensive report, that dives in to the nitty-gritty of an attack it cries out to be shared and should be cherished, voraciously dissected, pillaged for any tactical or strategic indicators and then carved up for lessons learned  whenever they surface.   So when an IR report was published today and I read it, I got rather excited*. There have been a number of stories on ColdFusion attacks over the last year. Brian Krebs had reported on a particular interesting case [1] of attacks against ColdFusion, but despite Brian’s excellent pieces, I hadn’t found the real technical meat of what happened and how.    RSA's Incident Response Team today published [2] their findings dealing with a particular adversary that took advantage of a known vulnerability in ColdFusion and used as a bridgehead to gain access to the internal network then fully compromise it and exfiltrate data across multiple forms and companies. I won’t spoil the read, (the full PDF is here [3]) but they provide plenty of exacting details, the tools techniques and procedures used , their own suggested lessons learned and a stack of indicators of compromise [4] for you to run against your own networks.    To me, reports like these should be compulsory reading if you're in a security role. Following the twists and turns an attacker took to get that initial compromise then how they pivoted inside a network and pillaged the data. We as security people need to understand what and how these other firms were compromised, then flip the attack on your own systems and see how we can detect or protect against becoming the next breach story in the spotlight.   If you know of any other papers you believe IR teams should have to read on the details of a breach , add them in the comments or send them in to us [5]   [1] http://krebsonsecurity.com/2013/10/adobe-to-announce-source-code-customer-data-breach/  [2] https://blogs.rsa.com/dissecting-tactics-techniques-advanced-adversary/ [3] http://www.emc.com/collateral/white-papers/h12756-wp-shell-crew.pdf [4] http://www.emc.com/collateral/white-papers/h12756-rsa-incident-response-emerging-threat-profile.zip [5] https://isc.sans.edu/contact.html#contact-form   * In a proper Internet Storm Center Handler manner, of course. Lots of nodding and the like.

 

Chris Mohan --- Internet Storm Center Handler on Duty

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

ISC StormCast for Wednesday, January 22nd 2014 http://isc.sans.edu/podcastdetail.html?id=3794, (Wed, Jan 22nd)

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

Taking care when publishing Citrix services inside the corporate network or to the Internet, (Tue, Jan 21st)

Tue, 01/21/2014 - 15:17

Citrix has some interesting products like XenApp, which allow people to access corporate application from tablets, Windows Terminals and also Windows servers and PC. Depending on how are you using them, you might be creating vulnerabilities to your information assets.

  • If you are using it inside the corporate network, it will use Pass-Through authentication with your windows domain authentication protocol. If you already have kerberos, you have nothing to worry about. You should not have any (NT)LM hash circulating through your network.
  • If you are using Citrix on the Internet, it is published in a IIS Web Server. Implementations can be done using username/password authentication or username/password/One Time Password. Unfortunately, many companies still believe that having an extra authentication factor is too expensive and difficult to handle, including the misconception of "I will never have my identity stealed".

Let's talk about published applications on Citrix with no extra authentication factor in place, which corresponds to the majority of cases. Since people tend to use mobile devices these days and also when they are big bosses in the company they want to handle their information in the most easy way, most of them requires IT to publish the ERP payments module, because they can authorize them from any place in any situation that allows them to have two minutes to perform the operation.

If the company happens to handle lots and lots of money, attackers might talk to any inside employee willing to have some extra money. First thing to do is to determine if the Citrix Farm linked to the Citrix Access Gateway where the user is being authenticated publishes the ERP Payment Application. How can you you do that? you can use the citrix-enum-apps nmap script. The syntax follows:

nmap -sU --script=citrix-enum-apps -p 1604 citrix-server-ip

If the attacker gets an output like the following, the company could be definitely in big problems:

Starting Nmap 6.40 ( http://nmap.org ) at 2014-01-21 17:38 Hora est. Pacífico, Sudamérica
Nmap scan report for hackme-server (192.168.0.40)
Host is up (0.0080s latency).
rDNS record for 192.168.0.40: hackme-server.vulnerable-implementation.org
PORT     STATE SERVICE
1604/udp open  unknown
|   OW ERP8 Payroll
|   OW ERP8 Provider payments
|   Internet Explorer
|   AD Users and Computers

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

Bingo! Provider payments is being published. All we need to do is perform good-old-man-in-the-middle to the IIS Server and we will have a username/password to generate random payments.

How can you remediate this situation?

  • Using username/password authentication it's definitely a BAD idea. Extra authentication factors needs to be placed and specially for users with critical privileges.
  • Configure your mobile clients to accept the specific server certificates and instruct them to interrupt any connection that shows a certificate error.
  • Ensure that Citrix Access Gateway server is the only one allowed to contact to the Citrix Server via UDP port 1604 and also that Citrix Farm is not accessible to the Internet or the corporate Network.

Manuel Humberto Santander Peláez
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. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Tuesday, January 21st 2014 http://isc.sans.edu/podcastdetail.html?id=3791, (Tue, Jan 21st)

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

You Can Run, but You Can't Hide (SSH and other open services), (Mon, Jan 20th)

Mon, 01/20/2014 - 10:35

In any study of internet traffic, you'll notice that one of the top activities of attackers is to mount port scans looking for open SSH servers, usually followed by sustained brute-force attacks.  On customer machines that I've worked on, anything with an open port tcp/22 for SSH, SFTP (FTP over SSH) or SCP will have so many login attempts on these ports that using the system logs to troubleshoot any other problem on the system can become very difficult.

We've written this up many times, and often one of the initial things people do - thinking that this will protect them - is move their SSH service to some other port.  Often people will choose 2222, 222 or some "logical" variant as their new home for SSH, this really just takes away the background noise of automated attacks, real attackers will still find your service.  We've covered this phenomena and real options for protecting open services like SSH in the past (google for ssh inurl:isc.sans.edu for a list)

What got me thinking about this was a bit of "data mining" I did the other night in the Dshield database using the reporting interfaces on the ISC site, as well as our API.  Port 22 traffic of course remains near the top of our list of ports being attacked:
https://isc.sans.edu/port.html?startdate=2013-01-01&enddate=2014-01-16&port=22&yname=sources&y2name=targets

However, this past week we saw an unusual spike in TCP port 222:
https://isc.sans.edu/api/topports/records/10/2014-01-13
and
https://isc.sans.edu/api/topports/records/10/2014-01-14

 

On the 14th, port 222 actually topped our list.  This event only lasted 2 days, and was primarily sourced by only two IP addresses.  Note the other spike in December.

https://isc.sans.edu/port.html?port=222

 

This looked like a full internet scan for port 222, sourced from these two addresses (I won't call them out here).  Looking closer at the IP's, they didn't look like anything special, in fact one was in a DSL range, so two days for a full scan is about right, given the fast scanning tools we have these days and bandwidth a home user will usually have.

The moral of the story?  No matter where you move your listening TCP ports to, there is someone who is scanning that port looking for your open service.  Using a "logical" approach to picking a new port number (for instance, 222 for scp or ssh, 2323 for telnet and so on) just makes the job easier for the attacker.  And that's just accounting for automated tools doing indiscriminate scanning.  If your organization is being targetted, a full port scan on your entire IP range takes only a few minutes to set up and will complete within an hour - even if it's on a "low and slow" timer (to avoid your IPS or to keep the log entry count down), it'll likely be done within a day or two.  Moving your open service to a non-standard port is no protection at all if you are being targetted.

If you don't absolutely need to have a service on the public internet, close the port.  If you need to offer the service, put it behind a VPN so that only authorized folks can get to it.  And in almost all cases, you don't need that SSH port (whatever the port number is) open to the entire internet.  Restricting it to a known list of IP addresses or better yet, putting it behind a VPN is by far the best way to go.  If you MUST have "common target" services like SSH open to the internet, use certificates rather than or in addition to simple credentials, and consider implementing rate limiting services such as fail2ban, so that once the brute-force attacks start, you've got a method to "shun" the attacker (though neither of these measures will protect you from a basic port scan).

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

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

ISC StormCast for Monday, January 20th 2014 http://isc.sans.edu/podcastdetail.html?id=3788, (Mon, Jan 20th)

Sun, 01/19/2014 - 21:45
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Anatomy of a Malware distribution campaign, (Sun, Jan 19th)

Sun, 01/19/2014 - 10:41

Starting about 10 days or so ago, a Spam campaign began targeting Pacific Gas and Energy (PG&E), a large U.S. energy provider. PG&E has been aware of this campaign for about a week, and has informed its customers.

This is yet another Spam run targetting the customers of U.S. energy companies that has been going on for several months.  I was able to get  two samples of this run to disect. This is not a campaign targetted directly at known PG&E customers  One of the emails came to an account which I only use as a garbage collector. I have not used the account in about ten years and nobody would legitimately send me email on that account. The second sample came from an ISC handler in Australia.  Neither of us are anywhere near PG&E's service area. 

It wasn't long ago that you could identify Spam by the quality of the English, but these emails look quite professional and the English is good.  The only real issue in the email being formatting of some of the currency figures.

The header  revealed that it was sent from user nf@www1.nsalt.net using IP 212.2.230.181, most likely a compromised webmail account.   Both the from and the reply-to fields are set to do_not_reply@nf.kg, an email address that bounces.   The 212.2.230.181 IP, the nf.kg domain and the nsalt.net domain all map to City Telecom Broadband in Kyrgyzstan (country code KG).

These sorts of runs usually have one of two purposes; credential theft, or malware distribution. In this case the goal of this particular campaign seems to be malware distribution. The "click here" link in the two samples point to different places  

  • hxxp://s-dream1.com/message/e2y+KAkbElUyJZk38F2gvCp7boiEKa2PSdYRj+YOvLI=/pge

  • hxxp://paskamp.nl/message/hbu8N3ny7oAVfvBZrZWLSrkYv2kTbwArk3+Tspbd2Cg=/pge

Both of these links are now down, but when they were alive they both served up PGE_FullStatement_San_Francisco_94118.zip which contained a Windows executable.

The Antivirus on my test machines were not triggered by this file and Virustotal has a 5/48 detection rate indicating this is most likely a Trojan Dropper:

I get 500 or so Spam and Phishing messages every day.  Fortunately the majority of them are caught in the excellent filters I have in place. This email passed those filters and if I was a PG&E customer would probably look legitimate enough to at least make me look at it twice before disregarding it as Spam.  But how many less tech-savvy PG&E customers got caught by this?  It is clear that modern anti-virus is dying as a front line defense against such attacks.  Is there a technology in the development pipe today that is going to step up and help protect the average user?

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

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

The Matasano/Square microcontroller CTF - http://bit.ly/1dvP6sa, (Fri, Jan 17th)

Fri, 01/17/2014 - 13:33
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Massive RFI scans likely a free web app vuln scanner rather than bots, (Fri, Jan 17th)

Fri, 01/17/2014 - 13:28

On 9 JAN, Bojan discussed reports of massive RFI scans. One of the repetitive artifacts consistent with almost all the reports we've received lately is that the attackers are attempting to include http://www.google.com/humans.txt. I investigated a hunch, and it turns out this incredibly annoying script kiddie behavior is seemingly, rather than bots, thanks to the unfortunate misuse of the beta release of Vega, the free and open source web application scanner from Subgraph.

One of the numerous Vega modules is Remote File Include Checks found in C:\Program Files (x86)\Vega\scripts\scanner\modules\injection\remote-file-include.js.

Of interest in remote-file-include.js:

var module = {
  name: "Remote File Include Checks",
  category: "Injection Modules"
};
function initialize(ctx) {
  var ps = ctx.getPathState();
  if (ps.isParametric()) {
    var injectables = createInjectables(ctx);
    ctx.submitMultipleAlteredRequests(handler, injectables);
  }
}
function createInjectables(ctx) {
  var ps = ctx.getPathState();
  var injectables = ["http://www.google.com/humans.txt",
                     "htTp://www.google.com/humans.txt",
                     "hthttpttp://www.google.com/humans.txt",
                     "hthttp://tp://www.google.com/humans.txt",
                     "www.google.com/humans.txt"];
    var ret = [];
    for (var i = 0; i < injectables.length; i++)
      ret.push(injectables[i]);
     return ret;
}

Great, now the kiddies don't even need to figure out how to make RFI Scanner Bot or the VopCrew Multi Scanner work, it's been dumbed down all the way for them!

What steps can you take to prevent and detect possible successful hits?

  • Remember that the likes of Joomla and WordPress, amongst others, are favorite targets.
    • If you're using add-on components/modules you're still at risk even if keeping these content management systems (CMS) or frameworks (CMF) fully up to date. As always, you're only as strong as your weakest link.
    • Component/module developers are not always as diligent as the platform developers themselves; believe me when I say the Joomla team cares a great deal about the security of their offering.
    • Audit add-on components/modules you have installed, see if there are any open vulnerabilities for them via https://secunia.com/advisories/search, and ensure you're utilizing the most current version.
  • Check your web site directories for any files written during or soon after scans.
    • If the remote file inclusion testing proved successful, the attackers will turn right around and drop a file(s) typically.
    • Such files could be a TXT, PHP, or JS file but they also like image file extensions too and will often drop them in the images directory if the vulnerability permits.
  • Yours truly has been dinged by this issue; you have to remember to keep ALL related code current or kiddies will have their way with you.
  • Check your logs for successful 200 (successful) responses where the humans.txt file was attempted, particularly where the GET string includes a path specific to your CMS/CMF.
  • Hopefully you see only 404 (not available) responses, but if you do see a 200 it warrants further investigation.
    • 404 example entry: 192.64.114.73 - - [05/Jan/2014:18:16:13 +0800] "GET /A-Blog/navigation/search.php?navigation_end=http://www.google.com/humans.txt? HTTP/1.0" 404 927 "-" "-"
    • 200 example entry: 192.64.114.73 - - [05/Jan/2014:18:29:29 +0800] "GET /configuration.php?absolute_path=http://www.google.com/humans.txt? HTTP/1.0" 200 - "-" "-"

Now that we know it's less likely bot behavior and more likely annoying miscreants, take the opportunity to audit your Internet-facing presence particularly if you use a popular CMS/CMF.

Cheers and feel free to comment or send additional log samples.

Russ McRee | @holisticinfosec (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

New and updated VMWare security advisories - http://www.vmware.com/security/advisories, (Fri, Jan 17th)

Thu, 01/16/2014 - 23:31
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Friday, January 17th 2014 http://isc.sans.edu/podcastdetail.html?id=3785, (Fri, Jan 17th)

Thu, 01/16/2014 - 20:30
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Port 4028 - Interesting Activity, (Thu, Jan 16th)

Wed, 01/15/2014 - 18:06

Take a look at port 4028.    Thanks to Bill for sharing an analysis that concluded a piece of malware was an Aidra botnet client. His shared analysis asks for a deeper look at port 4028.   I found a published write up from Symantec. [1]

After looking at our port 4028 data [2], there is reason to watch for it.   Please chime in if you are seeing any traffic on port 4028.

# portascii.html # Start Date: 2013-12-01# End Date: 2014-01-15 # Port: 4028 # created: Thu, 16 Jan 2014 01:34:07 +0000 # Date in GMT. YYYY-MM-DD format. date records targets sources tcpratio 2013-12-01 19 2 2 100 2013-12-04 18 2 2 100 2013-12-05 28 4 6 100 2013-12-06 8 2 2 100 2013-12-07 13 5 7 85 2013-12-08 9 5 7 67 2013-12-09 13 3 4 100 2013-12-10 23 5 6 100 2013-12-11 5 3 5 80 2013-12-12 19 3 3 100 2013-12-23 4 2 3 100 2013-12-25 6 2 3 100 2014-01-04 49240 45589 3 100 2014-01-05 1559 1440 40 100 2014-01-08 28910 26975 4 100 2014-01-09 6 6 3 83 2014-01-10 4531 3675 4 100 2014-01-11 76271 72307 3 100 2014-01-13 239 173 3 100 2014-01-14 195 164 6 99 2014-01-15 10 5 2 90 # (c) SANS Inst. / DShield. some rights reserved. # Creative Commons ShareAlike License 2.5 # http://creativecommons.org/licenses/by-nc-sa/2.5/

 

[1] http://www.symantec.com/security_response/writeup.jsp?docid=2013-121118-5758-99
[2]  https://isc.sans.edu/port.html?&startdate=2013-12-17&enddate=2014-01-16&port=4028&yname=sources&y2name=targets

 

 

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

ISC StormCast for Thursday, January 16th 2014 http://isc.sans.edu/podcastdetail.html?id=3782, (Thu, Jan 16th)

Wed, 01/15/2014 - 17:13
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Wednesday, January 15th 2014 http://isc.sans.edu/podcastdetail.html?id=3779, (Wed, Jan 15th)

Tue, 01/14/2014 - 17:49
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Oracle Critical Patch Update January 2014, (Tue, Jan 14th)

Tue, 01/14/2014 - 17:40

Today we also got Oracle's quarterly "Critical Patch Update". As announced, we got a gross or 144 different patches from Oracle. But remember that these patches affect 47 different products (if I counted right).

The product we are overall most worried about is Java. With this CPU, 34 security vulnerabilities are fixed in Java SE. So again: Patch or disable (fast).

http://www.oracle.com/technetwork/topics/security/cpujan2014-1972949.html

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

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