A few weeks ago I gave a presentation with the above title at some corporate
infosec event. Given I’ve been asked for the slides many times now, I’ve
converted them to a PDF which can be found
here.
We hope to contribute to the necessary debate thereby…
Some of us had the pleasure to participate in this year’s
Daycon VII, three days of Real Hacking and Relevant
Content, in Dayton, OH. The event began on September 16th with the Packetwars
bootcamp. We had the chance to teach some really promising young students and to
prepare them for the Packetwars battle that was scheduled four days later. The
students had to go through topics like Windows security, network security and
web application security both practical and in theory.
today we welcomed Michael Ossmann at the
ERNW headquarter for an exclusive workshop on his
HackRF
gadget. Everybody was quite excited to get hands-on with this shiny piece of
hardware, which is currently
crowd-funded on Kickstarter.
For everybody who’s not familiar
with Software Defined Radio (SDR):
Let’s regard it as the ultimate tool when working with radio signals.
Michael Ossmann in the house.
Let’s quote Michael’s campaign website:
Transmit or receive any radio signal from 30 MHz to 6000 MHz on USB power
with HackRF. HackRF is an open source hardware project to build a Software
Defined Radio (SDR) peripheral.
With HTML 5 the current web development moves from server side generated content
and layout to client side generated. Most of the so called HTML5 powered
websites use JavaScript and CSS for generating beautiful looking and responsive
user experiences. This ultimately leads to the point were developers want to
include or request third-party resources. Unfortunately all current browsers
prevent scripts to request external resources through a security feature called
the Same-Origin-Policy. This policy specifies that client side code could only
request resources from the domain being executed from. This means that a script
from example.com can not load a resource from google.com via
AJAX(XHR/XmlHttpRequest).
I’m currently catching up on a lot of papers and presentation from the
Usenix Security Symposium
in order to finish the blog post series I started last week (summarizing
WOOT and
LEET). One presentation, which
unfortunately is not available online [edit: see also update,
videos
are available now], included several particularly relevant messages that I want
to share in this dedicated post. Chris Evans, the head of the Google Chrome
security team (herein short: GCST), described some new approaches they employed
for their security team operations, some lessons learned, and how others can
benefit from it as well (actually the potential of these messages to make the
world a safer place was my motivation to write this post, even though I got
teased for supposedly being a Google fanboy 😉 ):
SUSE Linux Enterprise Server (SLES) has been around since 2000. As it is
designed to be used in an enterprise environment the security of these systems
must be kept at a high level. SLES implements a lot of basic security measures
that are common in most Linux systems, but are these enough to protect your
business? We think that with a little effort you can raise the security of your
SLES installation a lot.
This is the first part of an article that will give an overview of known
vulnerabilities and potential attack vectors against commonly used Virtual
Private Network (VPN) protocols and technologies. This post will cover
vulnerabilities and mitigation controls of the Point-to-Point Tunneling Protocol
(PPTP) and IPsec. The second post will cover SSL-based VPNs like OpenVPN and the
Secure Socket Tunneling Protocol (SSTP). As surveillance of Internet
communications has become an important issue, besides the traditional goals of
information security, typically referred as confidentiality, integrity and
authenticity, another security goal has become explicitly desirable: Perfect
Forward Secrecy (PFS). PFS may be achieved if the initial session-key agreement
generates unique keys for each session. This ensures that even if the private
key would be compromised, older sessions (that one may have captured) can’t be
decrypted. The concept of PFS will be covered in the second post.
Truncating TLS Connections to Violate Beliefs in Web Applications Ben Smyth and Alfredo Pironti, INRIA Paris-Rocquencourt
This presentation was also given at
BlackHat
some weeks ago. It outlines a very interesting class of attacks against web
applications abusing the TLS specification which states that “failure to
properly close a connection no longer requires that a session not be resumed
[…] to conform with widespread implementation practice”. This characteristic
enables new attack vectors on shared systems where certain outgoing (TLS
encrypted) packets can be dropped in order to prevent applications from e.g.
correctly finishing transaction (such as log out procedures) or even modifying
the request bodies by dropping the last parts.
I have the pleasure to visit this year’s
USENIX Security Symposium
in Washington, DC. Besides the nice venue close to the
national mall, there are also
several co-located workshops. Every night I will try and provide a summary of
those presentations I regard as most interesting. However, I hope to manage to
keep up with it as there are a lot of interesting events, people to meet, and
still some projects to keep up with. The short summaries below are from the 6th
USENIX Workshop on Large-Scale Exploits and Emergent Threats.
A recent post describing some nasty
vulnerabilities in HP
multifunction devices (MFDs)
brings back memories of a
presentation
Micele and I gave at Troopers11
on MFD security. The published vulnerabilities are highly relevant (such as
unauthenticated retrieval of administrative credentials) and reminded me of some
of the basic recommendations we gave. MFD vulnerabilities are regularly
discovered, and it is often basic stuff such as hardcoded $SECRET_INFORMATION
(don’t get me wrong here, I fully appreciate the quality of the published
research, but it is just surprising — let’s go with this attribute 😉 — that
those types of vulnerabilities still occur that often). Yet many environments
do not patch their MFDs or implement other controls. As it is not an option to
not use MFDs (they are already present in pretty much every environment, and the
vast majority of vendors periodically suffer from vulnerabilities), let’s recall
some of our recommendations as those would have mitigated the risk resulting
from the published vulnerability: