Internet Information Services (IIS) contains several components that perform important functions for the application and Web server roles in Windows Server. As it is designed to be used in an enterprise environment, the security of this system must be kept at a high level.
Similar to the documents we released for Linux and Windows (and actually inspired by a comment to the post on the Linux guide) Antonios wrote another guide, this time for Mac OS X.
Following up on this post, we want to provide some details on two rather new (well, compared to its lifespan) Linux kernel parameters — and emphasize the need to enable those:
After we recently released the “Linux IPv6 Hardening Guide” we got a number of suggestions “could you pls provide a similar document for $OS?” (btw: thanks to you all for the overwhelming interest in the Linux document and the active discussion of ip6tables rule approaches on the ipv6hackers mailing list).
We were recently approached by a customer asking us for support along the lines of “do you have any recommendations as for strict hardening of IPv6 parameters on Linux systems?”. It turned out that the systems in question process quite sensitive data and are located in certain, not too big network segments with very high security requirements.
continuing our tradition from last year (see here and here), we summarized more of our hardening recommendations for you. This guide is covering Tomcat 7 and is supposed to provide a solid base of hardening measures. It includes configuration examples and all necessary commands for each control, specifically for the most recent branch of Tomcat as there were some significant changes. Download: ERNW_Checklist_Tomcat7_Hardening.pdf
SUSE Linux Enterprise Server (SLES) has been around since 2000. As it is designed to be used in an enterprise environment the security of these systems must be kept at a high level. SLES implements a lot of basic security measures that are common in most Linux systems, but are these enough to protect your business? We think that with a little effort you can raise the security of your SLES installation a lot.
We have compiled the most relevant security settings in a SLES 11 hardening guide for you. The guide is supposed to provide a solid base of hardening measures. It includes configuration examples and all necessary commands for each measure. We have split the measures into three categories: Authentication, System Security and Network Security. These are the relevant parts to look for when hardening a system. The hardening guide also includes lists of default services that will help to decide which services to turn off, which is an essential step to minimize the attack surface of your system.
In the course of a recent endpoint assessment, we also had a OS X 10.8 client system as a target. While we still rely on the Firewire “capability” of unlocking systems on a regular base (using this great tool), we noticed that Apple released a patch to disable Firewire DMA access whenever the system is in a locked state (e.g. with an active screensaver or no user logged in). As we test the Firewire DMA access vulnerability quite often (at least we thought so 😉 ) to prepare for demonstrations in the board room or client assessments, we were quite surprised that we must have actually missed that nice update. In order to verify the effectiveness of the patch, we ran our typical test bed and can quite happily confirm that the update successfully mitigates Firewire DMA access in locked system states.
Beside breaking into unpatched OS X client using Firewire DMA access ;-), we also noticed some lack of hardening guides related to Apples current OS X version 10.8, so we also compiled a basic checklist for OS X hardening measures which we want to share with you: ERNW_Checklist_OSX_Hardening.pdf
Hi everybody,
eye-catching title of this post, huh?
Actually there is some justification for it ;-), that is bringing this excellent document covering the exact topic to your attention.
Other than that this post contains some unordered reflections which arose in a recent meeting in a quite large organization on the “common current iPad topic” (executives would like to have/use an iPad, infosec doesn’t like the idea, business – as we all know – wins, so bring external expertise in “to help us find a way of doing this securely” yadda yadda yadda).
Which – given those nifty little boxes are _consumer_ devices which were probably never meant to process sensitive corporate data – might be a next-to-impossible task… at least in a way that satisfies business expectations as for “usability”…[btw: can anybody confirm my observation that there’s a correlation between “rigor of restriction approach” to “number of corporate emails forwarded to private webmail accounts”?]
Anyway, in that meeting – due to my usual endeavor to look at things in a structured way – I started categorizing flavors of data wiping. I came up with
a) device-induced (call it “automatic” if you want) wipe. Here the trigger (to wipe) comes from the device itself, usually after some particular condition is met, which might be
number of failed passcode entries. This is supposed to help against an opportunistic attacker who “has found an iPad somewhere” and then tries to get access. Still, assuming a 4-digit passcode, based on their distribution the attacker might have a one-in-seven chance to succeed when the number of passcodes-to-fail is set to ten (isn’t this is the default setting? I don’t use such a device so I really don’t know ;-)).
check some system parameter (“am I jailbroken?”) and then perform a wipe.This somehow raises a – let’s call it – “matrix problem”: “judge the world’s trustworthy state from the own perspective and then delete my memory if found untrustworthy”. But how can I know my decision is a correct one if my own overall (“consciousness”) state might heavily depend on the USB port I’m connected to…
phone home (“Find My iPhone” et.al.), find out “I’m lost or stolen”, quickly wipe myself.This one requires a network connection, so a skilled+motivated attacker going after the data on the device will prevent this exact (network) connection. As most of you probably already knew ;-).
b) remote-wipe. That largely overhyped feature going like “if we learn that one of our devices is lost or stolen, we’ll just push the button and, boom, all the data on the device is wiped remotely”.
Unfortunately this one requires that the organization is able to react once the state of the device changed from “trustworthy environment” to “untrustworthy environment”. Which in turn usually relies on processes involving humans, e.g. might require people to call the organization’s service desk to inform them “I just lost my iPad”… which, depending on various circumstances that I leave the reader to imagine, might happen “in close temporal proximity to the event” or not …
And, of course, a skilled+motivated attacker will prevent the network connection needed for this one, as stated above.
So, all these flavors of wiping have their own share of shortcomings or pitfalls. At some point during that discussion I silently asked myself:
“How crazy is this? why do we spend all these cycles and resources and life hours of smart people on a detective+reactive type of control?”
Why not spend all this energy on avoiding the threat in the first place by just not putting the data on those devices (which lack fundamental security properties and are highly exposed to untrustworthy human behavior and environments)?
Which directly leads to the plea expressed in my Trooperskeynote “Do not process sensitive data on smartphones!” (but use those just as display terminals to applications and data hosted in secure environments).
Yes, I know that “but then we depend on network connectivity and Ms. CxO can’t read her emails while in a plane” argument. And I’m soo tired of it. Spending so much operational effort for those few offline minutes (by pursuing the “we must have the data on the device” approach) seems just a bit of waste to me [and, btw, I’m a CxO “of company driven by innovation” myself ;-)]. Which might even be acceptable if it wouldn’t expose the organization to severe risks at the same time. And if all the effort wasn’t doomed anyway in six months… when your organizations’ executives have found yet another fancy gadget they’d like to use…
Think about it & have a great sunday,
Enno
PS: as we’re a company with quite diverse mindsets and a high degree of freedom to conduct an individual lifestyle and express individual opinions, some of my colleagues actually think data processing on those devices can be done in a reasonable secure way. See for example this workshop or wait for our upcoming newsletter on “Certificate based authentication with iPads”.
I can’t help myself. And I fully understand that some of you, dear readers, might get a bit annoyed by always hearing the same tune from our side. This post is, surprise!, about yesterday’s Microsoft Patch Tuesday which – as can be seen here and here – disclosed quite a number of vulnerabilities in various Microsoft components. To make the point evoked in this post’s title I’d like to draw your attention to two particular bulletins, both rated as critical.
The advisory states that “this security update resolves a publicly disclosed vulnerability in Microsoft .NET Framework. The vulnerability could allow remote code execution on a client system if a user views a specially crafted Web page using a Web browser that can run XAML Browser Applications (XBAPs)”.
Looking at the “Workarounds” section, it turns out that the configuration of some specific parameters within Internet Explorer (those are: Loose XAML, XAML browser applications, XPS documents, Run components not signed with Authenticode, Run components signed with Authenticode) would prevent a successful attack, including potentially future ones against the vulnerable components. Disabling those parameters (amongst others) is exactly what this document suggests.
To quote from the advisory itself: “this security update resolves a privately reported vulnerability in Microsoft Windows GDI+. The vulnerability could allow remote code execution if a user viewed a specially crafted image file using affected software or browsed a Web site that contains specially crafted content”.
Here, in the “Workarounds” section disabling metafile processing is listed as a potential one. Which, in turn, we’ve recommended here.
So, to cut the chase: once more proper hardening could have been your friend, at least for those two “critical” ones.And yes, we’ve already taken the potential business impact of these measures into account. We can safely state that in many environments there’s practically none. But not having to worry about some of yesterday’s advisories and maybe even avoiding getting owned (for MS11-029 Microsoft estimates that it’s “likely to see [a] reliable exploit developed in [the] next 30 days”) might have some benefit in pretty much every organization. Think about it!