Bold Statements
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.
thanks
Enno
Continue readingAfter 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,
Matthias
Continue readingThis 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…
thanks
Enno
Continue readingA 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:
You understand that in order to provide the Service and make your Content available thereon, Apple may transmit your Content across various public networks, in various media, and modify or change your Content to comply with technical requirements of connecting networks or devices or computers. You agree that the license herein permits Apple to take any such actions.And in addition, the Apple Privacy Policy states the following:
You further consent and agree that Apple may collect, use, transmit, process and maintain information related to your Account, and any devices or computers registered thereunder, for purposes of providing the Service, and any features therein, to you., which kind of reminds of the Dropbox Terms of service which even state that they are allowed to transfer your data to anybody if it is necessary in order to assure the quality of the offered service. Thinking of the trust factor components, all of these risks are getting even more relevant since Apple relies on third party cloud services (which are Amazon Web Services and Azure, according to several sources, including this one), which conclusively must also fulfill certain security requirements in order to lower the vulnerability factors for the presented risks.
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 ;-).
So stay tuned… Matthias
Continue readingDuring the last days, some of our guys (including me) had some great days in Dayton. Rene, Christopher, Hendrik, Sergej, and me flew in to give workshops and presentations at Day-Con as well as to compete in the infamous PacketWars game. While Day-Con is a one day event, the two days before the conference comprised workshops on secure iOS integration (given by Rene) and IPv6 security (given by Christopher). Since the overall topic of the conference was trust, Rene gave a keynote on broken trust which was based exemplary trust analysis, development of a trust metric, and different trust factors. Those trust factors were also used in my talk about evaluation methodologies for cloud service providers (regular followers will recognize some of the content of both talks from different posts 😉 ). There were also talks from Sergey Bratus, Graeme Neilson and Angus Blitter. While Sergey proposed a sound (not to say academic 😉 ) definition on the classification of vulnerabilities and their connection to turing complete input languages, Angus gave an introduction to PowerLine technologies and laid out, that these technologies still suffer from naive assumptions about trusted networks (he also refered to this). The day after the conference, the ERNW Allstars had to defend their championship title in PacketWars. Since the first battle was scheduled for 10AM, we had quite some time to tan in the sunny 30°C weather, recover from the conference and prepare the expected victory celebration (some of you might remember some “Champagne tradition” from Troopers). In face of this motivation, we rushed through the 3 battles and were able to score first place second year in a row. At this point, kudos to the two other participating teams who gave us a tough battle, especially during the reversing challenges.
Have a great week, Matthias
Continue readingWe recently performed a Proof-of-Concept (PoC) implementation of certificate based auth with iPads in some large environment. So far the focus has been mainly on WLAN access; VPN and EAS authentication are going to follow in the next step.
As we figure that the topic might be of interest for some of you, we’ve extracted a certain, not-too-customer-specific part of the deliverable and converted it into an ERNW newsletter. Special thanks go to Rene Graf for leading the project! 😉
Of course, this stuff is going to be covered in much more detail in the Troopers12 edition of our “iOS Security Workshop” (see here for the agenda of this year or here for a German version of the current one).
Enjoy reading (& implementing)!
thanks
Enno
Continue readingAfter having introduced the basic elements of our concept of trust, control and confidence in this post, today I’ll try to strengthen your (and maybe even my own as well ;-)) understanding of these ideas by applying them to another candidate, that is Dropbox. Hence this post is mainly about performing a certain analysis method to some object; conclusions as for the question if Dropbox is suited to be used in enterprise environments processing sensitive data are out of scope and are left entirely to you, the valued reader.
Two more preliminary remarks might be helpful to further understand the direction and intent of this post:
a) I don’t have any practical experience with Dropbox. I don’t use it personally and at ERNW using it for company-related data would require a risk acceptance, which – probably not too surprisingly – no company member has ever filed (and which would have a quite high likelihood of being turned down by the CEO anyway ;-)). In other words: I can’t imagine any occasion we’d use cloud based storage services for any of our data. It’s just that – given our idea of “highly skilled, thoughtful and responsible humans working here” – we don’t use terms like “xy is strictly forbidden” very often…
So feel free to jump in by PM or comment to this post if this stated lack of practical experience has lead to wrong conclusions or factual errors.
b) This post is not about blocking Dropbox in corporate networks by technical means (which – afaik – is relatively easy compared to, say, blocking Skype, as DB seems to operate mainly from a well-defined /24 network range). Doing so (technically blocking DB on corp firewalls) would not solve the underlying problem of potentially misplaced trust (or ignorance) and might just lead to yet-another-risk-acceptance popping up on the ISOs’ desks (I know, I know: some of you would be happy if at least a risk acceptance existed for DB within your organization…). And, of course, the corp_fw way would not address the aggregate problem of running Dropbox on mobile devices (at least assumed that no cloud based proxy services are in use for those, which is currently the case in most networks I know).
However this post is about asking a certain set of questions and clarifying some company’s or service’s attributes to induce a reasonable discussion about the exact company’s/service’s suitability for processing sensitive assets. To us, such an approach is aligned with our understanding of an ISO as a trusted business advisor (as opposed to the “paranoid pitbull” or “unfortunately unheard master of governing guidelines” mission understanding of ancient times).
Now let’s have a look at the object of today’s trust exercise, that is Dropbox. Founded in 2007 and fueled by US$ 7.2 million venture capital (as of this Forbes article) the California-based company provides cloud-based file storage services with a simple GUI and some nice collaboration capabilities for groups of users sharing files. The description in the CrunchBase profile goes: “Always have your stuff, wherever you are”. A technical overview can be found in this paper recently presented at USENIX Security.
As you might recall from the first post of this series, there I laid out some trust contributing factors, which I took from the ISECOM “Mastering Trust” methodology that is taught in their Trust Analyst course (pls note that my interpretation of these may be wrong as I never attended that course. sorry, Pete ;-)).
These are:
Applying all these to Dropbox might yield the following answers:
a) Size
While this might seem a simple one given Dropbox is a not-too-big company presumably held by their founders and some investors/venture capital providers (plus maybe employees holding stocks or options or sth) it should be noted that, more or less obviously, there’s more entities in the overall picture => see below at section “Components”.
b) Symmetry
Usually this one is hard to apply to B2C scenarios, so I’ll skip it here.
c) Transparency
Honestly, as I’m not a user of their service I don’t have a ultimate attitude here. However from a trust analyst point of view I just note there’s a number of people out there who think that DB failed severely in this regard. And there’s a (still pending?) complaint for injuctive relief filed to the FTC stating that Dropbox “continues to make deceptive statements to consumers regarding the extent to which it protects and encrypts their data.”
So overall this one (transparency) seems at least debatable; see also discussion on factor “Integrity” below.
d) Consistency: well, probably most of you know that three months ago DB suffered a breach which exposed all online storage lockers to anyone entering any password for ~ 4 hours.
Strictly taking the “consistency road” this does not contribute to their trustworthiness, from my humble evaluation.
e) Integrity
This post from the Hunton & Williams privacy blog provides an overview how Dropbox’ security statements (on its website) changed over time. I tend to assume the majority of users is/was not aware of those changes. In general it seems that one of their main communication channels is their blog. Which – given that most of you probably read a blogpost right now 😉 – might certainly be a valid channel… for B2C scenarios in modern times at least. Not sure if this is the right channel for the security properties of corporate information assets though.
f) Components
This is a particularly interesting one. As obvious as this may be, most users are probably not aware that DB does not operate the servers providing the service themselves. To the best of my knowledge the (Dropbox) service heavily relies on Amazon S3 and EC2 instances, in a certain setup that Mulazzani et.al., in their paper, comment on as follows: “However, the fact that encryption and storage is done at the same place seems questionable to us, as Amazon is most likely able to access decryption keys”.
g) Porosity
We can’t provide an evaluation here as we do not dispose of any information as for clear demarcation lines on the financial (e.g. who might potentially influence DB’s decisions due to simple ownership of shares ;-)) or organization/infrastructure (which 3rd parties actually provide which type of supporting service, e.g. do they share their office space with other parties in a business/office incubator etc.) sides of things.
If some people within your organization are still going to use DB for corporate data then, well, that’s an “educated decision by business” [no, no, the quotes are not put here to hint there might be a contradictio in adjecto ;-)].
Stay tuned for more stuff to come in this series & have a good week,
Enno
btw: we’ll probably have a talk about Dropbox at next year’s Troopers which takes place on 03/21 and 03/22 2012 in Heidelberg.
… the corrupt DEA agent in Luc Besson’s great movie “Léon (The Professional)”. I’m sure quite some of you, dear readers, know the plot…
Just before the final shootout, when sending the first men of the NYPD ESU team into Léon’s apartment, he tells them to “Be careful!”. After learning those men got killed he just comments: “I told you”.
[btw: before yelling to bring “EEEEEEEVERYONE!!!!”, as those familiar with the piece will certainly remember ;-)].
I’m fully aware that I risk playing “the arrogant scumbag card” today and that it’s generally not very nice to refer to one’s own earlier statements with an “I told you” attitude (especially if harm was caused to some party), but this is exactly how I feel when reading these news. And – pls believe me – it’s an expression of utmost despair.
How often do organizations have to be told that running Adobe Flash might not be the greatest idea in the world, security-wise? How many statistics like this one (see section “Vulnerabilities” in the bottom part of it) have to see the light of the world until people realize that (quoting from this blogpost) “running Flash on corporate desktops is simply asking for trouble. Asking for trouble loudly. Very loudly.”?
When we wrote this document on configuring IE8 securely we pointed out that using Adobe Flash required a risk acceptance, from our perspective. Man, how I was attacked! for this very statement afterwards in the customer environment that document was initially developed for. I’ve since mentioned Flash in this blog here, here and here.
Furthermore we’ll include a talk on Flash in next year’s Troopers line-up, I promise. And be it only to avoid this post sounding like a crusade of a bitter old man… (yes, this was a wordplay referring to some character from the movie ;-).
yours sincerely
Stansfield
Continue reading
A few days ago the European Network and Information Security Agency (ENISA) published this quite interesting document with the exact title. Here’s what it covers:
“The booming smartphone industry has a special way of delivering software to end-users: appstores. Popular appstores have hundreds of thousands of apps for anything from online banking to mosquito repellent, and the most popular stores (Apple Appstore, Google Android market) claim billions of app downloads. But appstores have not escaped the attention of cyber attackers. Over the course of 2011 numerous malicious apps were found, across a variety of smartphone models. Using malicious apps, attackers can easily tap into the vast amount of private data processed on smartphones such as confidential business emails, location data, phone calls, SMS messages and so on. Starting from a threat model for appstores, this paper identifies five lines of defence that must be in place to address malware in appstores: app review, reputation, kill-switches, device security and jails.”
Just read through it and while I’ve never been a big fan of STRIDE (mainly due the application centric approach which simply is not my cup of tea) I have to say it’s applied elegantly to the “app ecosystem” described in the paper.
The doc somewhat accompanies this one titled “Smartphones: Information security risks, opportunities and recommendations for users” (released by ENISA in late 2010), which is a valuable resource in itself.
Overall excellent work from those guys in Heraklion, providing good insight from and for practitioners in the field.
Have a great weekend everybody
Enno
Continue readingA few weeks ago, I released version 0.9 of a web application testing tool called tsakwaf (The Swiss Army Knife for Web Application Firewalls) together with an ERNW Newsletter about web application firewalls. tsakwaf is based on perl and supports fingerprinting of some supported WAFs and code generation methods to circumvent filter rules. Today, version 0.9.1 will be released, which adds SSL support for the WAF fingerprinting function (Big thanks to Simon Rich!) and a bug fix regarding the detection of WAF reactions which may lead to false positives. Additionally, I’m happy to announce that at least one talk at next year’s Troopers will cover attacks against WAFs (like this one from the 2009 edition) . So mark your calendar – Troopers12 will happen on 21st and 22nd March 2012, with the usual workshops before the conference and the round table sessions the day after – and enjoy playing with tsakwaf!
Download here.
thanks
Frank
Continue reading