Simple everyday work dialog:
“The heater in the basement is still missing a proper thermostat, the ‘binary solution’ isn’t that effective”
– “Buy one…”
– “Ok”
– “Get one you can break…”
– “Ok, but then I’d like a few tools, too”
– “Go for it.”
(That’s the way work should be!)
Result of the dialog: a Danfoss Living Connect Z ( 014G0013 ) and a TI CC1100 Wireless Mini Dev Kit plus a copy of Z-Force to start with. Goal: Talk to the thermostat!
We’re sometimes approached with the question “Which IPv6 mailing lists do you guys read/subscribe to?” – here’s a quick overview of the main ones guys like Christopher, Patrick, Rafael, Antonios and myself are periodically lurking at, to discuss IPv6 (network|security) related stuff with other practitioners and to learn from them:
During our first year of testing Windows Phone 8 applications we had yet another, let’s say: “surprising” finding. It all started with the first approaches on pentesting mobile applications on that new and rather closed platform. Lacking jailbreak, root, and similar approaches we had a closer look at alternate approaches to have a look at an apps interior. We quickly hooked onto using modified firmwares (with deeper system access) and found a perfect solution in a little flaw concerning the handling of SD cards in WP8.1. A flaw that was, sadly for us, fixed silently….
Just recently, Dell SecureWorks Counter Threat Unit(TM) (CTU) researchers published details (see http://www.secureworks.com/cyber-threat-intelligence/threats/skeleton-key-malware-analysis/ ) on a especially nasty piece of malware that bypasses authentication on Active Directory (AD) systems which implement single-factor (password only) authentication. Once deployed the malware stays quite noiseless in the Domain Controller´s (DC) RAM, and the DC´s replication issues caused by it weren´t interpreted – in this case – during months as a hint for system compromise. Probably the malware´s modification on the LSASS process reduced the DC´s ability to perform DC-to-DC authentication, but this is only speculation and not where we would like to go today.
So, what to do? The relevant mitigations, pointed out by Dell´s CTU, as event log monitoring and scanning processes on suspicious systems with the published YARA signature should be applied.
Still, let’s discuss for a second which long-term, preventative measures could come into play as well. Continue reading “Skeleton Key – a Nasty Piece of Malware. Some Remarks.”
during our BlackHat US 2014 talk titled “Evasion of High-End IPS Devices in the Age of IPv6”, among others we discussed a Snort preprocessor rule (116:456) which, when enabled (not the case by default), triggers an alert when an IPv6 datagram with nine (9) or more IPv6 Extension Headers is used (such a header was used by us to evade Snort). However, we mentioned that:
As every year some of us used the holidays to visit the Chaos Communication Congress to socialize with like-minded people and to hear interesting talks.
I mean what other reasons than learning about security might exist to leave behind all your lovely in-laws you’ve been sharing some relative’s house with the days before … 😉
Here is a short recap of some of the talks we found most interesting:
RA Guard Evasion is well-known in the IPv6 “circles”; there is RFC 7113 Advice for IPv6 Router Advertisement Guard (RA-Guard) and many interesting blog-posts like this one here, here, and this excellent write-up here that discuss this issue.
Moreover, as Jim Smalls states in his comprehensive “IPv6 Attacks and Countermeasures” presentation given at the North American IPv6 Summit 2013, DHCPv6 Guard or a corresponding IPv6 ACL can stop a DHCPv6 Rogue Servers, but (only?) for non-malicious/non-fragmented DHCPv6 packets (slide 35). However, at that time there wasn’t any known attack tool in the wild that had the fragmentation evasion built in.
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).
This brought up a number of more generic questions:
a) Should such packets having as source address the IPv6 loopback one be processed at all?
b) Which OSs process such packets?
c) How can we protect our systems from them?
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: