As we come to the end of the year we can’t help but take a moment to thank all of your who made TROOPERS15 special! It just makes us all the more pumped to kick it up a notch for TROOPERS16!! #BestWeekEver
Happy Holiday and much Joy to you in the New Year!
In this part of our little series (part 1, part 2, part 3) we continue discussing IPv6 specific filtering of network traffic, namely at intersection points.
As stated in the 1st part, a number of potential security problems in IPv6 networks are related to Extension Headers of IPv6, in particular when combined with fragmentation. At the same time, as of today (December 2015) there is no Internet service or application that actually needs those headers.
As part of my research on the security of paravirtualized devices, I reported a number of vulnerabilities to the Xen security team, which were patched today. All of them are double fetch vulnerabilities affecting the different backend components used for paravirtualized devices. While the severity and impact of these bugs varies heavily and is dependent on a lot of external factors, I would recommend patching them as soon as possible. In the rest of this blog post I’ll give a short teaser about my research with full details coming out in the first quarter of 2016 .
Here at TROOPERS HQ we are well into the Holiday (read TROOPERS) Spirit so we thought we would publish another round of talks! The current agenda can be found here.
So this is the third part of our little series on securing IPv6 in enterprise environments. In the first part we tried to develop an understanding of threats in IPv4 networks as a kind-of baseline while analyzing the main differences induced by IPv6 and in the second part we laid out protection strategies on the infrastructure level, focusing on network isolation on the routing layer. Today I’ll dive into discussing IPv6-specific filtering of network traffic.
In this blogpost we will briefly explain a well known Syscall hooking technique (a more detailed explanation can be gathered from e.g. http://resources.infosecinstitute.com/hooking-system-service-dispatch-table-ssdt/) used by multiple malware samples (like the laqma trojan) and right after discuss how some memory analysis tools have trouble in the analysis and/or reporting of these. Continue reading “Investigating Memory Analysis Tools – SSDT Hooking via Pointer Replacement”
In the first part of this series we tried to identify which risks related to network-related threats actually change when IPv6 gets deployed and hence which ones to take care of in a prioritized manner (as opposed to those which one might be tempted to [initially] disregard with a “has been there in IPv4 already and we did not address it then, why now?” stance). Let’s assume we went through this step and, for those most relevant risks we identified, we want to come up with infrastructure level controls first, before tackling controls to be deployed on the host level (as in many organizations the sysowners of “hosts” like servers in datacenters tend to expect “the network/infrastructure guys to provide the 1st layer of defense against threats”, in particular once those originate from an apparent network layer protocol, that is IPv6).