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:
We were recently approached by a customer asking us for support along the lines
of “do you have any recommendations as for strict hardening of IPv6 parameters
on Linux systems?”. It turned out that the systems in question process quite
sensitive data and are located in certain, not too big network segments with
very high security requirements.
They indicated they were willing to spend significant operational resources on
“securely configuring them”. So Antonios deciced to write a small hardening
guide for IPv6 on Linux, mostly focusing on manual configuration of pretty much
everything (including neighbor cache entries 😉 with accompanying deactivation
of all automatic mechanisms, together with ip6tables based local packet
filtering.
The document
can be found here.
We just released a white paper authored by
Antonios Atlasis that provides an
overview which pentesting tools currently support IPv6 and how to (still) use
them if that’s not the case. It can be found
in our newsletter section.
Mike Ossmann: RF Retroreflectors, Emission
Security and SDR
Synopsis: The leaked pages from the NSA ANT catalog provided a glimpse into the
modern world of emission security. Extending beyond passive monitoring of
unintentional emissions, today’s spooks employ active attacks with tools such as
RF retroreflectors. I’ll report on my experiments to reproduce such techniques
with open source hardware and software, primarily using SDR.
When planning for IPv6 addressing, many organizations – rightfully & wisely –
decide to go with global unicast addresses (GUAs) only (hence not to use
unique local addresses/ULAs as of
RFC 4193 at all), in order to avoid
address selection hell or just for
simplicity & consistency reasons. This
post discusses security implications and complementary security controls of such
an approach.
In their IPv4 networks, most of these organizations currently use RFC 1918
space, combined with NAT for specific connections or use cases. Ideally NAT is
only in place “where strictly needed”, in practice it’s often used as a
kludge to
conceal of all types of bad network design or debatable application
architectures. I won’t enter the “is NAT a security control?” debate here, one
statement might be allowed though: as of section 3 (“Because private addresses
have no global meaning, routing information about private networks shall not be
propagated on inter-enterprise links, and packets with private source or
destination addresses should not be forwarded across such
links.”) RFC 1918 space is usually not
reachable from the Internet. So using such address space for internal networks
is a nice example of the isolation principle as of the
“Seven Sisters”
approach we like to use. Now, bringing NAT into these networks enables
connections (usually between trusted and untrusted networks) which simply would
not be possible without it [NAT], so this actually breaks the isolation
property. Question: how can one ever call something that increases the
number of possible interactions between assets and potential attack originators
a ‘security control’?!