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”?]
Today I’m proudly releasing the first version of apnbf, a small python script
designed for enumerating valid APNs (Access Point Name) on a GTP-C speaking
device. It tries to establish a new PDP session with the endpoint via sending a
createPDPContextRequest. This request needs to include a valid APN, so one can
easily distinguish from a valid APN (which will be answered with a
createPDPContextResponse) and an invalid APN (which will be answered with an
error indication message). In addition the tool also parses the error indication
and displays the reason (which should be “Missing or unknown APN” in case of an
invalid APN).
So, after having a completely new release yesterday, we will stay with already
known but updated software today. You might have heard of gtp_scan before, which
is a small python script for scanning mainly 3G and 4G devices and detecting GTP
(GPRS Tunneling Protocol) enabled ports. As GTP is transported via UDP and we
all know, UDP scanning is a pain, the tool uses the GTP build-in echo mechanism
to detect GTP speaking ports. Since the last version I’ve implemented some new
features:
I’m proud to announce, today a new fuzzing framework will see the light of day.
It’s called dizzy and was written because the tools we used for fuzzing in
past didn’t match our requirements. Some (unique) features are:
Python based
Fast!
Can send to L2 as well as to upper layers (TCP/UDP/SCTP)
Ability to work with odd length packet fields (no need to match byte borders,
so even single flags or 7bit long fields can be represented and fuzzed)
Very easy protocol definition syntax
Ability to do multi packet state-full fuzzing with the ability to use received
target data in response.
We already had a lot of success using it, now you will be able to know the true
promises.
Some days ago a security advisory related to web application firewalls (WAFs)
was published on Full Disclosure. Wendel Guglielmetti Henrique found another bug
in the IBM Web Application Firewall which can be used to circumvent the WAF and
execute typical web application attacks like SQL injection (click here for
details). Wendel talked already (look
here)
at the Troopers Conference in 2009 about the different
techniques to identify and bypass WAFs, so this kind of bypass methods are not
quite new.
This again is going to be a little series of posts. Their main topic – next to
the usual deviations & ranting I tend to include in blogposts 😉 – is some
discussion of “trust” and putting this discussion into the context of recent
events and future developments in the infosec space. The title originates from a
conversation between Angus Blitter and me in a nice Thai restaurant in Zurich
where we figured the consequences of the
latest RSA revelations.
While we both expect that – unfortunately – not much is really going to happen
(surprisingly many people, including some CSOs we know, are still trying to
somehow downplay this or sweep it under the carpet, shying away from the –
obvious – consequences it might have to accept that for a number of environments
RSA SecurID is potentially reduced to single factor auth nowadays…), the long
term impact on our understanding of 3rd party (e.g. vendor) trust might be more
interesting. Furthermore “Broken Trust” seems a promising title for a talk at
upcoming Day-Con V… 😉
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.