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.
