This is the third (and last) part of the series (parts
1
&
2
here). We’ll provide the results from some additional tests supported by public
cloud services, namely AWS (Amazon Web Services).
Lab Setup
The Amazon Elastic Compute Cloud (short: EC2) provides a flexible environment
for the on demand provisioning of virtual machines of different performance
levels. For our lab setup, a so-called extra large instance was used. According
to Amazon, the technical specs are the following:
In the
first post
I’ve laid out the tools and lab setup, so in this one I’m going to discuss some
results.
Description of overall test methodology
To evaluate the performance of the different setups used to analyze capture
data, both tcpdump and pcap_extractor (see last post) were used. For the tests,
five capture files were created using mergecap. Various sample traffic dumps
were merged to five large files with different file sizes. All these files
consisted of several capture files containing a variety of protocols (including
iSCSI and FCoE packets). Capture files of ∼40, ∼80, ∼200, ∼500, and ∼800 GB size
were created and were analyzed with both tools. For all tests the filtering
expressions for tcpdump and pcap_extractor were configured to search for a
specific source IP and a specific destination IP matching to iSCSI packets
contained in the capture file. Additionally pcap_extractor was “instructed” to
look for some search string (formatted like a credit card number).To address the
performance bottleneck (again, see last post), that is the I/O throughput, two
different setups of the testing environment (see above) were implemented, the
first one going with a raid0 approach using four SSD hard drives, the second one
with four individual SSD hard drives, each of them processing only a fourth of
the analyzed capture file. Standard UNIX time command was invoked to measure the
time of execution. Additionally the tools analyzing the data were started with
the highest possible scheduling priority to ensure execution with the maximum of
available resources. This is a sample command line invoking the test:
Hi,
didn’t find the time so far to post a short blog about
HITB Amsterdam so far…
but here we go.
Unfortunately I couldn’t arrive in AMS earlier than Thursday evening so I missed
the first day (and – from what I heard – some great talks). However we went out
for dinner that night with the likes of Andreas (Wiegenstein), Jim (Geovedi),
Raoul (Chiesa), Travis (Goodspeed), Claudio (Criscione) and some more guys and I
had some quite good conversations, both on technical matters and on
Intra-European cultural differences ;-). Btw: thanks again to Martijn for taking
care of the restaurant.
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:
As I’m currently developing the ‘next gen’ state-full fuzzing framework @ERNW
[called dizzy, to be released soon 😉 ], I will give you an updated set of
fuzzing scripts from the ‘old world’.
Some of you will remember the 2008 release of sulley_l2, which was a modified
version of the sulley fuzzing framework, enhanced with Layer 2 sending
capabilities and a hole bunch of (L2) fuzzing scripts. All the blinking,
rebooting, mem-corrupting ciscos gave us some attention. Back from then, we
continued to write and use the fuzzing scripts, so the hole collection grew.
There is a common misconception that the sheer amount of data coupled with
multiplexed channels (e.g. WDM technology) make successful eavesdropping attacks
on high speed Ethernet links – like those connecting data centers – highly
unlikely. This is mainly based on the assumption that the amount of resources
(e.g. RAM, [sufficiently fast] storage or CPU power) needed to process large
files of captured data is a limiting factor. However, to the best of our
knowledge, no practical evaluation of these assumptions has so far been
performed.
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.
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.
Lots of stuff has been written about
this blog post from RSA
describing the (potential) details of the attack, so I will refrain from
detailed comments on this piece that Marsh Ray nicely called “some of the most
egregious hyperbole I’ve read in infosec”.
Just one short note. Presumably the attack, in an early stage, used a
“spreadsheet [that] contained a zero-day exploit that installs a backdoor
through an Adobe Flash vulnerability (CVE-2011-0609)”.