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