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.
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:
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! 😉
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.
This advisory
describes an interesting attack vector:
“In the period of December 2010 until August 2011, Cisco shipped warranty CDs
that contain a reference to a third-party website known to be a malware
repository. When the CD is opened with a web browser, it automatically and
without warning accesses this third-party website. Additionally, on computers
where the operating system is configured to automatically open inserted media,
the computer’s default web browser will access the third-party site when the CD
is inserted, without requiring any further action by the user.”
Hi everybody,
eye-catching title of this post, huh?
Actually there is some justification for it ;-), that is bringing
this excellent document covering the exact topic
to your attention.
Other than that this post contains some unordered reflections which arose in a
recent meeting in a quite large organization on the “common current iPad topic”
(executives would like to have/use an iPad, infosec doesn’t like the idea,
business – as we all know – wins, so bring external expertise in “to help us
find a way of doing this securely” yadda yadda yadda).
Which – given those nifty little boxes are _consumer_ devices which were
probably never meant to process sensitive corporate data – might be a
next-to-impossible task… at least in a way that satisfies business expectations
as for “usability”…[btw: can anybody confirm my observation that there’s a
correlation between “rigor of restriction approach” to “number of corporate
emails forwarded to private webmail accounts”?]
A couple of hours ago Christopher (Werny) and I gave
this presentation
well-organized event bringing together a number of practitioners from the field.
While yesterday’s talks were dominated by a certain euphoria and optimistic
pioneer spirit, the second day featured some security talks which induced slight
shadows to the brave new world of IPv6 ;-). I particularly enjoyed meeting Eric
Vyncke from Cisco (one of the two authors of
this great book)
and Marc “van Hauser” Heuse who released a new version of the
THC-IPV6 tool set today. We had some fruitful
discussions and we took the opportunity to test some of his newly implemented
attacks against “RA Guard” running on a 4948E Chris and I had brought for a demo
within our talk. Unfortunately – or fortunately in terms of a
“from theory to reality”
approach – I have to say that Marc found a quite clever way to circumvent RA
Guard by putting the actual “RA payload” into a second frame following a first
one mostly containing a “long & empty” destination option (after a fragmentation
header pointing to the mentioned second one). To get an idea pls see these
screenshots from Wireshark.
Hi,
I’ve discussed the concept of evaluating the operational “feasibility” (or
“impact”, depending on your point of view) of security controls
before.
Some people approached me asking “which considerations should we take into
account when trying to understand or rate this for $SOME_SECURITY_CONTROL?”.
Therefore, in the following I’ll give an unordered list of factors to consider
to get an understanding of the “operational feasibility” of a given security
control. Two things should be noted in advance:
I can’t help myself. And I fully understand that some of you, dear readers,
might get a bit annoyed by always hearing the same tune from our side. This post
is, surprise!, about yesterday’s Microsoft Patch Tuesday which – as can be seen
here and
here
– disclosed quite a number of vulnerabilities in various Microsoft components.
To make the point evoked in this post’s title I’d like to draw your attention to
two particular bulletins, both rated as critical.