Most of you are probably aware of the recently discovered/-closed severe ntpd
vulnerabilities (CVE-2014-9293, CVE-2014-9294, CVE-2014-9295, CVE-2014-9296, see
also
the initial ntp.org security notice).
Some days ago the Project Zero team at Google published a blog post
“Finding and exploiting ntpd vulnerabilities”
with additional details. In this one they mentioned a seemingly minor but quite
important detail: on a default OS X installation one of the built-in protection
mechanisms of ntpd (that is the restriction to process certain packets only if
they are sourced on the local machine) can easily be circumvented by sending
IPv6 packets with a spoofed source address of ::1 (the equivalent to 127.0.0.1
in IPv4 which would be discarded by the kernel once received from an external
source).
We’re currently starting the preparation for the
Troopers15PacketWars Challenge, and since I’ve participated in
quite some CTF games and have been involved in the preparation of a number of
PacketWars Battles, I thought I’d write down some thoughts on the design of
hacking challenges.
First of all, my experience is limited almost exclusively to attack-defend-CTFs
or interactive war games (such as PacketWars or
CCDC).
While thinking about this blogpost, I also came across several terms which are
used, so I decided to give a short summary:
Happy new year and all the best for 2015 to everybody!
Here’s the next round of Troopers15 talks (all the others can be found
here):
===
Marion Marschalek & Moti Joseph: The Wallstreet of Windows Binaries
FIRST TIME MATERIAL
Synopsis: Nowadays common ways to find exploitable vulnerabilities include
but are not limited to fuzzing, static and dynamic analysis and patch reversing.
All common approaches have advantages and limits. Fuzzers tend to only find a
limited number of bugs, depending on the sophistication of the fuzzer which is
indirectly dependent on the development time invested. Reverse engineering a
binary for finding bugs, regardless whether statically or with a debugger, is
tedious and requires a lot of time and expertise.
As we are lazy bastards, we refuse to do all the work by hand and brain. And, as
we are greedy bastards, we want a maximum scope of vulnerabilities we can cover
and not be limited to what we see from a fuzzers perspective.
So as you know – in general the lazy greedy bastards have the better ideas. We
present you with our idea, which is built after the model of the Wallstreet. We
built a tool which weighs the value of a function in a Windows binary as the
Wallstreet values a stock; the value telling us the likability of a function to
be exploitable.
The Wallstreet technique works with two different evaluation methods, for once
the likability that a function is vulnerable and also the likability that it is
exploitable.
We collect indicators, which help us evaluate that a specific function is
potentially vulnerable. Such could be a present memory allocation or conversion
function, a lacking sanitization check or a suspicious pattern in the
functionname such as ‘create’, ‘convert’ or ‘set’. A combination of these and a
handful more indicators lets us calculate what we call the speculation value.
For the validation of the exploitability we traverse the call tree of a
suspicious candidate, to verify its accessibility in an automated way. Only
functions which we can influence as an attacker are interesting for us; thus we
rate these accessible functions with a price-to-earnings value. Finally putting
speculation value and price-to-earnings value in context, we evaluate a function
with either ‘buy’ if we believe it comes with an exploitable vulnerability, or
with ‘sell’ when we are certain it is not interesting to us. No worries, the
presentation will not contain advanced mathematical equations.
Our tool parses binaries and persists all the gathered information to a
database, from where we can retrieve highly suspicious functions in an automated
way. Without getting our hands dirty, that is. And because we are lazy bastards
who like colors, a lot, we use visuals to make evaluation even easier. The tool
is dubbed Wallstreet, free after the most famous stock market on the planet. It
is based on Python, C and SQLite and will be released under the WTFPL license
(http://www.wtfpl.net/). Also, there will be demos 😀
Wrapping it up, this presentation shows an easy to use approach which makes the
complicated topic of binary exploitation more accessible. Wallstreet of Windows
Binaries provides beginners with better understanding of the challenges and
practitioners with a hands-on tool.
As follow up of our 2014 talk
“LTE vs. Darwin”
I want to inform you about our telco research in 2015. We are currently dealing
with the so called IP Multimedia Subsystem (IMS), which handles the call and
media logic of 4G telecommunication networks. This network part provides
functions like VoIP (or VoLTE) and takes care of the interconnection to other
call or media related networks.
Following up on
this post,
we want to provide some details on
two rather new
(well, compared to its lifespan) Linux kernel parameters — and emphasize the
need to enable those:
fs.protected_hardlinks
fs.protected_symlinks
For BSD, similar parameters for hardlinks exist:
security.bsd.hardlink_check_uid/security.bsd.hardlink_check_gid.
Those parameters control whether users are allowed to create links pointing to
files which are not owned by them. If fs.protected_hardlinks/symlinks is set
to 1, users can only create links to files which they own. Attackers have used
this possibility for a long time, and here are some sample attack scenarios:
As we promised some days ago here’s the fourth round of Troopers15 talks (the
first three can be found here). We really
can’t wait for the con ourselves 😉 !
Arrigo Triulzi: Pneumonia, Shardan, Antibiotics and Nasty MOV: a Dead Hand’s
Tale FIRST TIME MATERIAL
Synopsis: Starting in the 80’s we will discuss the influence of nuclear weapons
on the design of an ITsec “Dead Hand” system for a security practitioner, how it
merged with research into firmware backdoors and microcode modification and
finally triggered when instead of enjoying Summer pneumonia struck unannounced,
or rather, announced by the Dead Hand via Twitter.
One interesting observation we make when testing complex environments is that at
the bottom of huge technology stacks, there is usually a handful of shell
scripts doing interesting stuff. More often than not these helper scripts are
started as part of cron jobs running as root and perform basic administrative
tasks like compressing and copying log files or deleting leftover files in
temporary directories. Of course, these high privileges make them an interesting
target for privilege escalation attacks and one class of vulnerability we
reliably encounter in shell scripts is unsafe handling of globbing or filename
expansions.
After we recently released the
“Linux IPv6 Hardening Guide”
we got a number of suggestions “could you pls provide a similar document for
$OS?” (btw: thanks to you all for the overwhelming interest in the Linux
document and the active discussion of ip6tables rule approaches on the
ipv6hackers mailing list).
Hence Antonios thankfully decided to put together a list of configuration steps
for Windows servers. It
can be found here.
Once more we’d like to emphasize that the approach described is only suited for
very specific environments with high security requirements and an associated
ratio of “generous operational resources”. From our perspective this guide is
intended mostly to serve as a source of inspiration (“what could be done”) and
for documentation purposes (“how to do it”). Everything described should be
carefully tested in your specific environment.
For example, we were recently involved in IPv6 security planning in an
organization where the Windows guys (completely legitimately) came up with a
stance of “before we fully accept and ratify the strategy and policy just
discussed, we’d like to get feedback from Microsoft, if we still have full
support once we follow this path”.
As we promised some days ago here’s the third round of Troopers15 speakers
(first
one here,
second
here).
It’s going to be awesome!
Andreas Lindh: Defender Economics FIRST
TIME MATERIAL
Synopsis: There are a lot of preconceptions about defense, the most prevalent
one probably the “defenders dilemma” in which it is stated that an attacker only
needs to find one weakness to compromise a network while a defender needs to
defend all of them. While this may be true in a technical sense, things become a
lot more complicated once you apply real world considerations. Preconceptions
like this are often the foundation on which risk management and ultimately
defense strategies are based, something that has led to a number of false but
generally accepted assumptions about attackers and their capabilities, and how
to defend against them.
This talk will discuss the capabilities, and more importantly the limitations,
of different types of attackers. Using the ancient wisdom of the Teenage Mutant
Ninja Turtles, the speaker will explain how knowledge of an attacker’s
limitations can be leveraged to raise the cost of attack, something that will
tip the scale in the defenders favor. The speaker will also explain how
different defensive measures will affect different types of attackers, how they
are likely to react to them, and in the end how to get them to hopefully move on
to another target.
Lately we had to analyze QR-Codes in a pentest. Those held some random data
which was used as a token for login and we wanted to know if that data was
really random.
If you ever worked with the Burp Suite you may know the Burp Sequencer, which
offers some statistical analysis regarding the randomness of tokens which appear
in requests (you just have to tell Burp what or where the token is). In our case
the QR-Code was delivered as an inline-image in HTML to the browser, like this: