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:
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:
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.
