Currently there’s quite some discussion ongoing why it took Apple so long to fix a severe vulnerability in the update process of iTunes. A severe vulnerability which could easily be exploited by means of an automated tool called evilgrade which can be downloaded here (Hi Francisco!). Just one small note here: did you know that evilgrade was first shown and released at the 2008 edition of Troopers? We had a number of initial releases of tools in the last years (like wafw00f at the 2009 edition and VASTO at the 2010 edition) and we will continue this fine tradition in 2012. I can already promise that some nice code is going to be released for the first time at Troopers12…
The above is the exact title of a Gartner research note published some days ago. Its main thesis is that an increased convergence of carriers’ MPLS and Internet infrastructures onto shared IP infrastructures requires that enterprises re-evaluate their security and performance risks.
While I do not agree with the overall line of reasoning in the paper, it still highlights a number of interesting points when it comes to MPLS security. Which in turn reminds me of quite some stuff we’ve done in the past, mainly our Black Hat Europe 2009 talk “All your packets are belong to us – Attacking backbone technologies”. Today we’ll release an updated version of the accompanying whitepaper as a kind-of technical report. Its title is “Practical Attacks against MPLS or Carrier Ethernet Networks” and it can be found here.
btw: for those of you who have actually read the Gartner paper… did you notice their repeated reference to customer RFIs/RFPs not covering a carrier’s separation between their public Internet and MPLS infrastructures? Here’s a document that describes how a given carrier’s trustworthiness might be evaluated and which furthermore contains an excerpt from an RFI (written back in 2006!) which, amongst others, ask for this very point…
On last year’s TROOPERS11, Matthias (mluft) and I gave a talk on Multifunction Devices. Hardly surprising: It was related to the state of secure operation of MFDs. It was heavily motivated by experiences we collected out in the wild. We faced a frightening low level of awareness concerning the role of MFDs for the overall security picture – in particular regarding the processing of sensitive data…
However, instead of only showing and proving well-known weaknesses and vulnerabilities, we decided to adapt ERNW’s Seven Sistersmodel in order to match the needs of secure MFD operation and to develop some kind of guideline. As Matthias already lost some words on this, I’m not gonna waste your valuable time by repeating, what has already been said. However I described our approach and our thoughts on that topic in a recently published ERNW Newsletter. If for what ever reason you didn’t see our talk or even didn’t attend TROOPERS11 at all, have a look on Newsletter 37 and give us feedback on what you think about the whole topic…
Btw: Enno just wrote some lines about what’s so special about the TROOPERS conference. In case you might want to discuss mentioned and related topics at first hand, think about joining TROOPERS12. For our part, we cannot wait to come together at Heidelberg next March.
Once again there’s a reference to some action movie here, as some of you may have immediately spotted ;-).
For the record: this one is from “Snake Plissken”, the main protagonist in John Carpenter’s “Escape from New York”. There’s another well-known quote of the same character in the kind-of sequel “Escape from L.A.” which goes like: “The more things change, the more they stay the same”. I’m aware that this is not the initial source (but French novelist Jean-Baptiste Alphonse Karr presumably is, at the time in French ;-)); still this gives a nice transition to today’s topic.
To make it short: there’s pieces of software out there which – regardless of ongoing attempts to patch or even rewrite them – just remain crap, security-wise. Regular readers of this blog may have seen (read) me mentioning some of those. Right now I’d like to draw your attention to another one of my all-time favorites in the “is crappy. has been crappy for a long time. will probably continue do to so for a long time” list. Curtain up! for ISC BIND.
ISC published this advisory today (in case you’re too lazy to follow the link, here some quick facts: “BIND 9 Resolver crashes after logging an error in query.c”; severity “serious”; exploitable “remotely”; CVSS 7.8). Apparently it’s exploited in the wild. It’s at least the 5th unauthenticated remote DoS in BIND 9 in the last twelve months (here’s their advisories). And here’s another quote, this time from the BIND 10 project page:
“The architecture of BIND 10 concentrates on these technical aspects: modularity, customizability, clusterization, integration, resilience, and runtime control.”
See what’s missing? You got it. So good luck to those of you still running BIND. Call it snake… oil…
This week I stayed some days in Zurich, to give a workshop and to meet both clients and fellow researchers (kudos again to C. for the awesome office tour @Google). In the course of one of those dinners somehow Troopers was mentioned and a guy asked: “I’ve heard of the conference. What’s so special about it?”
Funnily enough I didn’t even have to respond myself as a 2011 attendee coincidentally present at the table jumped in and started praising the event (“best con ever. great spirit, great talks”). Obviously this gave me a big grin… but it reminded as well me that some of you might ask themselves the very same question.
In my opening remarks of the 2011 edition I tried to describe the Troopers approach and spirit. You can find it here. As for the speakers’ perspective I’d like to point you to this blogpost that Chema (Alonso) wrote before the 2010 edition. It pretty much summarizes how we take care of “our rock stars”…
Btw: the CfP will be open in some days. As in the previous years, there are only few slots left (as most are already assigned to hand-selected speakers).
Here we go again: TROOPERS12 is scheduled for March 19th – 23rd 2012 in Heidelberg, Germany.
Those who attended TROOPERS before know for what we are up to. For all newcomers I’ll quickly outline what’s going to happen:
TROOPERS is your premium IT security event in Europe. Think of your usual IT educational event without annoying sales pitching and outdated topics. Now add a superb conference location, an elite line-up of international researchers and practitioners as well as an organizing team not dedicated to make a living doing this, but to celebrate our craftsmanship together with like-minded people.
Sounds good? Let’s see what we have planned for you:
Monday & Tuesday
We start with a great selection of workshops. You’ll have a bigger choice than ever before:
One-day workshops on Monday:
Advanced IPv6 Security
ISECOM Workshop (to be announced shortly)
One-day workshops on Tuesday:
Advanced Email Security
ISECOM’s “Smarter, Safer, Better” security awareness training
Special event on Tuesday:
We call it the “TelcoSec Day” – A workshop that assembles researchers and practitioners in the telecommunications operator security space. Invitation only. Please drop us an email, if you think you should be part of it.
Two-day boot camp on Monday and Tuesday:
Hacking 101 – Your personal preparation for PacketWars (and beyond…)
Wednesday & Thursday
These are the main conference days. Expect more than 20 international researchers coming in to present on their latest discoveries – ready to share their experience with you. In order to serve you with the latest and greatest we won’t announce a final agenda yet. Topics of already confirmed talks include:
Web Application Firewalls
We’ll finish up with a bunch of roundtable sessions. This is the perfect place to recap the week’s happenings and look ahead on upcoming developments.
Something is missing right?
A TROOPERS conference is more than a yearly get-together of some IT guys. This event is for enthusiasts, idealists and doers of all nationalities, age groups and sexes. Our common denominator is the passion for what we do and the strong belief that we will succeed in the daily battle of IT security. Professionals from various backgrounds are longing for an environment where their thoughts, work and experience is appreciated and amplified.
Therefore we spare no efforts to do just that. To name just a few highlights of your complimentary supporting program:
Shared dinner in the Old Town
PacketWars hacking contest
10k Morning run to keep you going
[TOP SECRET] Competition
Registration is open now. Head over to the sign up page and make yourself familiar with all the deals we offer. Please contact us, if you need any assistance or guidance on your selection.
We’re looking forward to meet you soon, Florian & the TROOPERS/ERNW crew
As a follow-up to this post somebody pointed us to this interesting article on S/MIME support and associated certificate mgmt in iOS 5. Nice read which some of you may find worthwhile.
On a related note: if anyone is aware of an easy way/good (3rd party) solution for pushing certs to iOS devices (besides SCEP) we would be very interested in that one. In that case pls leave a comment or shoot us an email.
After the basic iCloud discussion in this post, I would like to add some more technical information. The following items are just a loose compilation of facts about the mentioned controls which allow the restriction of iCloud usage. The basic iCloud usage, consisting of backup, document sync, and photo stream, can be deactivated using the most recent version of the iPhone Configuration Utility:
Since there are no default settings for these values, it is necessary to include the disabled entries in existing configuration profiles.
Another new functionality which can be deactivated using configuration profiles is Siri. Even though this functionality is not directly related to the iCloud at first glance, it still bears a big threat potential. Looking at the SLAs of the iPhone 4s, the following paragraph gets relevant: When you use Siri, the things you say will be recorded and sent to Apple to process your requests. Your device will also send Apple other information, such as your first name and nickname; the names, nicknames, and relationship with you (e.g., “my dad”) of your address book contacts; and song names in your collection (collectively, your “User Data”).
So Siri also uses cloud-based services in the background. The following screenshot shows the option to disallow the usage of Siri:
Thinking of this privacy relevant submission of data, another new option of the most recent tool version gets relevant: “Allow diagnostic data to be sent to Apple”. The two checked options in the following screenshots are also new features of the most recent version of the configuration utility:
That’s it for the short configuration option compilation of today, have a great week everybody,
This is a _very_ interesting paper just published by some researchers (mainly) from RUB (Ruhr-University Bochum). Here’s the abstract:
“Cloud Computing resources are handled through control interfaces. It is through these interfaces that the new machine images can be added, existing ones can be modied, and instances can be started or ceased. Effectively, a successful attack on a Cloud control interface grants the attacker a complete power over the victim’s account, with all the stored data included.
In this paper, we provide a security analysis pertaining to the control interfaces of a large Public Cloud (Amazon) and a widely used Private Cloud software (Eucalyptus).
Our research results are alarming: in regards to the Amazon EC2 and S3 services, the control interfaces could be compromised via the novel signature wrapping and advanced XSS techniques. Similarly, the Eucalyptus control interfaces were vulnerable to classical signature wrapping attacks, and had nearly no protection against XSS. As a follow up to those discoveries, we additionally describe the countermeasures against these attacks, as well as introduce a novel ‘black box’ analysis methodology for public Cloud interfaces.”
While the actual described vulnerabilities have been fixed in the interim this stresses once more the point we made in this post: the overall security posture of the management (or “cloud control” as the authors of the above paper call it) interfaces is crucial for potentially all the data that’s processed by/on your cloud based machines or applications.
Great research from those guys! This will help to drive the discussion and security efforts for a reasonable use of cloud based resources in the right direction…
A few days ago (on 10/12/2011) Apple launched its new cloud offering which is called — who would have guessed 😉 — iCloud. Since we’re performing quite some research in the area of cloud security, we had a first look at the basic functionality and concepts of the iCloud. Its main features include the possibility to store full backups of Apple devices (at least, an iPhone, iPad or iPod touch running iOS 5 or a Mac running OS X Lion 10.7.2 is required), photos, music, or documents online. The data to be stored online is initially pushed to the cloud storage and then synchronized to any device which is using the same iCloud account. From this moment on, all changes on the cloudified data is immediately synchronized to the iCloud and then pushed to all participating devices. At this point, most infosec people might start to be worried a little bit: The common cloud concept of centralized data storage on premise of a third party does not cope well with the usual control focused approach of most technical infosec guys. The resulting concerns can be attributed to several main cloud computing related risks (which are proposed by ENISA and actually very valuable work:
Lock In: According to the way the cloud functionality is integrated into iOS and OS X , usage of the iCloud might result in strong lock in effects. There is neither the possibility to use different backend cloud storage for the functionality nor the possibility to develop a product which provides similar functionality (see later paragraphs for examples).
Isolation Failure: is probably the most present threat for many IT people, since it is highly related to technical implementation details. It includes, but is not limited to, breakout attacks from guest systems due to vulnerabilities in the hypervisor or to unauthorised data access due to insufficient permission models in backend storage. Thinking of the trust factor consistency, Apple’s history of cloud based services was not their “finest hour” (as Steve Jobs stated during his keynote on iCloud). Remembering this talk and the awkward MobileMe vulnerabilities, we would agree with that 😉
Loss of Governance: The loss of governance over data in the cloud is kind of an intrinsic risk to cloud computing (also refer to the proposed system operation life cycle and the motivation given here). Again, referring to explanations about the technical iCloud implementation in the later paragraphs, this loss might be even more relevant in the iCloud environment.
There are some more risks according to the ENISA study, but those are beyond the scope of this post. If we do such rough assessments as sample exercises during our cloud security workshops, the participants usually ask what “they can do”. Possible controls can be divided into two groups: controls to reduce the risk to a reasonable level and controls which prohibit the usage of the particular service. When analyzing the cloud, the control always mentioned first is crypto. Speaking of cloud storage, crypto is a valid control to ensure that unauthorized access (e.g. due to isolation failure/physical access/subpoena) to data has no relevant impact. The only requirement is that the encryption is performed on client side (depending on the attacker model and whether you trust your cloud service provider). For example, Amazon provides a feature which is called Server Side Encryption which encrypts any file that is stored within S3. Additionally, Amazon allows the implementation of a custom encryption client which enables customers to perform transparent encryption of all files which are stored in S3. The analysis of the security benefits, attacker models, and operational feasibility of these controls will be the subject of yet-another blogpost, but at least Amazon offers these encryption features. The offered services of the iCloud differ a little bit in functionality (for example, the iCloud iTunes version is a kind-of music streaming platform), but basically there are two API functions which allow access to the iCloud backend. First, it is possible to store documents (where documents can be complete directory structures) in the iCloud, second, a so called key-value store can be accessed. The access is encapsulated in dedicated API calls which take care of the complete data transfer, synchronization, and pushing operations using an iCloud daemon. So any use of the iCloud is strictly connected to an app (I would have called it application ;-)) which has to use the introduced iCloud API calls. Even though I’m not that familiar with the iOS/OS X architecture, I would have guessed that it would have been easily possible to add client side encryption using the internal keychain and usual cryptographic mechanisms. Still, this is not the fact and it is questionable, regarding the user experience oriented focus of Apple, whether this feature will be implemented in the future. This lack of encryption possibility brings up the second class of controls, which shall restrict the iCloud usage. This is especially important in corporate context, where full backups of devices would potentially expose sensitive corporate data to third parties. Even though the usage might be restricted by acceptable use policies, this might not enough since the activation of this feature can happen accidentally: If a user logs in once into the iCloud frontend, which is possible using a regular apple ID, the data synchronization is enabled by default and starts immediately (refer also to the quoted terms of service above). Since most corporate environments use MDM solutions, it is possible to restrict the iCloud usage at least for iOS based devices. The corresponding configuration profiles offer several options to disable the functionality:
For today, this little introduction to iCloud and some of its security and trust aspects will be finished here. We will, however, continue to explore the attributes of iCloud more deeply in the near future (and we might even have a talk on it at Troopers ;-).