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.
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:
During 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 differentposts 😉 ). 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.
During our ongoing research on the security of cloud service providers and cloud based applications, we performed a regular audit of our AWS account password. Thinking of popular incidents and evergreens in attack vectors, we were wondering which consequences an online bruteforce attack on our AWS password would have. So we decided to perform a bruteforce attack against our own account. Analyzing the login process of AWS, the following requirements for the bruteforce tool to be used could be derived:
Recently Micele and I were researching for our talk about the current state of security of Multifunction Devices (MFDs). Since we’re both seasoned pentesters who are quite familar with MFDs, we were really surprised that very little new research is going on on the topic of MFD security. While diving deeper into the topic, we found a very simple explanation for this: As in 2002, it is still possible to download print or scan jobs using PJL, many devices still offer default FTP or Telnet access, and, of course, stored files can be recovered from MFD hard drives — on an enterprise wide scale. To even strengthen our impression of the current state of MFD security, most devices crashed or did go wild while performing some scans — and we do not talk about fuzzing here.
During the keynote of the Intel Developer Forum, Intel’s CEO Paul Otellini explained their motivation for the acquisition of McAfee. Basically, Intel wants to provide a possibility to shift computer security from a known bad model to something that is a known good model.
Coming back to some of our recentblog posts, we think that a reliable and working approach to implement application whitelisting would increase security in corporate environments — especially when thinking of the latest vulnerabilities with exploit code in the wild that could not be catched up by any AV solution. As covered by this article, the possibility that such an approach succeeds depends heavily on the critical mass that would use it. The widespread x86 architecture therefore is the perfect plattform for accomplishing a widely used known good model. Presuming the possibility for flexibel and secure operation, Intel’s efforts could be the chance to shift the paradigm of corporate security from a reactive to a preventive model.
