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.
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.
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.
We 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! 😉
After 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.
… 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 ;-)].
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.”
A 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 21^(st) and 22^(nd) March
2012, with the usual workshops before the conference and the round table
sessions the day after – and enjoy playing with tsakwaf!
I’m currently involved in a “Remote Access Security Assessment” and you might be
wondering what exactly this means. Well, so did we. At least to some degree
(btw: last year we provided some notes on types of security assessments
here).
It happens quite often we’re brought into an organization to perform “a security
assessment” of “some item” (“our network”, “that new procurement portal”, “the
PKI” etc.). It happens as well the customer does not have a very clear idea of
the way such an assessment should be carried out (telling us “you are the
experts, you should know what to do”). Or the five people from the customer’s
side present in the kick-off meeting have five different concepts (ok, four. as
one of them only wants “to get that damned assessment done so we can finally go
live”) and we end up moderating their arguments on what should be tested, how
this should be done, when this is going to happen, which type of report format
is needed (obviously, there’s different ones, depending on the
goal/scope/methodology of the assessment…) etc.
