Yesterday the US-CERT released a
Technical Alert (TA16-144A)
about the recently found WPAD Name Collision Vulnerability. We will give you a
summary about the vulnerability as well as the basic mechanisms here.
WPAD
The Web Proxy Auto-Discovery Protocol is used to auto-configure the proxy for
web browsers. So when joining the according network the browser can use DHCP and
DNS methods to find a specific configuration file (typically named wpad.dat),
which is loaded and applied to the browser’s settings. Therefore, there is no
need to configure each browser in your environment individually/manually.
Usually I’m not the kind of guy who talks about such economic topics. Because
I’m an engineer / security researcher who is exclusively concerned with
understanding technical problems and if possible, solving them accordingly. My
whole education is based on this and contains predominantly technical aspects of
information security. This sometimes makes it difficult to understand what the
market cares about (and why some products are being developed / exist on the
market 😉 ). Nevertheless, a current engagement for one of our customers made me
stumble upon such a product.
This blog post will give a brief overview about how a simple IoT device can be
assessed. It will show a basic methodology, what tools can be used for different
tasks and how to solve problems that may arise during analyses. It is aimed at
readers that are interested in how such a device can be assessed, those with
general interest in reverse engineering or the ones who just want to see how to
technically approach an unknown device.
I’ve recently found some sort of classic web vulnerabilities in the Google
Search Appliance (GSA) and as they are now fixed [0][1][2], I’d like to
share them with you.
First of all, some infrastructure details about the GSA itself. The GSA is used
by companies to apply the Google search algorithms to their internal documents
without publishing them to cloud providers. To accomplish this task, the GSA
provides multiple interfaces including a search interface, an administrative
interface and multiple interfaces to index the organization’s data.
White-box cryptography is a relatively new field that aims at enabling safely
cryptographic operations in hostile situations.
A typical example is its use in digital-right management (DRM) schemes, but
nowadays you also find white-box implementations in mobile applications such as
Host Card Emulation (HCE) and the protection of credentials to the cloud.
In all these use-cases the software implementation uses the secret key of a
third-party which should remain secret from the owner of the device which is
running this executable.
First of all: This is not an in-depth Kerberos how-to, nor is this tutorial
about the different aspects of web application testing. This tutorial is just to
give support in testing Kerberos authenticated web applications. The goal is to
hand over the right tools and steps to be able to perform the configuration and
be able to test the application.
When to use it?
When there is a 401 server response with the header “WWW-Authenticate:
Negotiate”. This can either mean Kerberos or NTLM authentication is needed. It
is possible to distinguish them by looking at valid authenticated client
traffic. As a simple reminder: The NTLM Authorization header will always start
with the value “TlRM…”, the Kerberos Authorization header will always start with
“YII…”. For further information this
link is
recommend.
In this tutorial the term “Kerberos authentication” will be used. There are
other terms sometimes used like SPNEGO, SSO or integrated authentication.
While running some SS7 pentests last year, I developed a small tool automating
some of the well-known SS7 attack cases. Today I’m releasing the first version
of ss7MAPer, a SS7MAP (pen-)testing
toolkit.
The toolkit is build upon the
Osmocom SS7 stack and implements
some basic MAP messages. At its current state tests against the
HLR are ready for use,
in future versions tests against
VLR,
MSC and
SMSC will follow.
The source code of the tool is published on
github, feel free to use and extend.
Some weeks ago Hendrik explained in his blogpost
Security Analysis of VoLTE, Part 1
some attack vectors for Voice over LTE (VoLTE). One attack vector introduced was
Denial of Service (DoS), which I also discussed in my Masterthesis “Evaluation
of IMS security and Developing penetration tests of IMS”.
In general, DoS attacks aim to prevent a system or a network from efficiently
providing its service to legitimate users . The impact of such attacks can vary
from a big degradation of quality to total blockage. DoS can occur on users
level, where a user or a group of users cannot use the service. But the common
conception of DoS is on the service level, where the whole service is broken,
unstable or totally down. This blog post is about targeting DoS of the whole
VoLTE service by attacking IMS.
A while back Stefan and I held a little crash course/orientation run on hardware
hacking at a German Fachhochschule. Planning to use something “real” we went for
a simple electronic safe with a bunch of different vulnerabilities. I guess most
security guys who spend a fair amount of time in hotels will understand this
choice. As we needed something we could rely on would break, we stripped the
device and swapped the original electronics for our own. The result was the
“Damn Vulnerable Safe”.
