IPv6 RA-Guard: How it works and how to defeat it
Most IPv4 networks are managed using DHCP and as a result are subject to attacks via rogue DHCP servers. In response, many switches implement "DHCP Snooping" as a feature to protect from these attacks.
As networks switch to IPv6, DHCP will become less used. Some operating systems, like for example OS X, don't even implement DHCPv6. Instead, router advertisements will be used to help systems discover the network and to configure themselves. But just like DHCP, router advertisements (RA) may be spoofed. To protect your network from rogue RAs, a switch may implement RA-Guard [1], a feature similar to DHCP Snooping.
RA-Guard will only forward RAs, if they are received on a port known to be connected to an authorized router. Additional filtering may happen based on the MAC address of the router.
A recent IETF draft outlines some deficiencies of RA-Guard and how to possibly evade RA-Guard. The basic premise of RA-Guard is that the switch, a layer 2 device, is able to inspect the IPv6 and ICMP6 headers (layer 3) as well as the ICMP6 payload in order to identify and interpret RAs. In particular for IPv6, this is not an easy task and the evasion techniques outlined in the IETF draft are a nice lesson in the difficulties of correctly interpreting IPv6 traffic.
First of all, there is the potential for extension headers. Router advertisements *should not* have any extension headers, but there isn't really anything to prevent that from happening and per RFC, it is legal. However, as soon as we are dealing with extension headers, the "Next Header" field in the IPv6 header can no longer be used to identify the packet as an ICMP6 packet. Instead, the switch will have to find the last header and use it's Next-Header field.
Processing the entire header chain will take more resources and in the end, may limit the through put of the switch or even lead to denial of service conditions.
Next, the RA messages may be fragmented. This is again a condition that should not be seen in a *normal* network, but then again, attackers may very well craft legal RA packets that are fragmented. The fragmentation could be used to only show the IPv6 header and some extension headers in the first fragment, and move the header indicating the ICMP6 header, as well as the actual ICMP6 header, to the second fragment. Of course, this could be made even more interesting with multiple fragments.
Oh... and remember: Wednesday is IPv6 day :) We will have more about that later.
[1] http://tools.ietf.org/html/rfc6105
[2] http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt
IPv6 Security Summit is coming July 15th, Washington DC, http://www.sans.org/ipv6-summit-2011
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Some Insight into Apple's Anti-Virus Signatures
Now with Apple pushing out its first daily update to combat the latest MacDefender variant, its a good time to take a closer look at "XProtect", the Snow Leopard Anti Malware engine (or to use the Apple euphemism: "safe download list").
OS X heavily relies on XML files for configuration. These "plist" files are easy to read. The same is true for the XProtect configuration, which includes the currently valid signatures. Two files are used:
/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist
This file appears to track XProtect versions, and when they got applied.
/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist
This is the actual signature file. For example, one of the MacDefender entries looks like:
<dict>
<key>Description</key>
<string>OSX.MacDefender.B</string>
<key>LaunchServices</key>
<dict>
<key>LSItemContentType</key>
<string>com.apple.installer-package</string>
</dict>
<key>Matches</key>
<array>
<dict>
<key>MatchFile</key>
<dict>
<key>NSURLNameKey</key>
<string>Info.plist</string>
</dict>
<key>MatchType</key>
<string>Match</string>
<key>Pattern</key>
<string>3C6B65793E43464276B6....F737472696E673E</string>
</dict>
[ ... 3 more 'dict' sections deleted ... Also, the string is appreviated to fit ]
</array>
</dict>
xpath /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist
/plist/array/dict/string
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
DroidDreamLight -> phone nightmare.
Kasperky Lab Security news service posted this recently.
https://threatpost.com/en_us/blogs/droiddream-returns-dozens-infected-apps-pulled-android-market-060111
“Researchers have identified a second large batch of apps in the Android Market that have been infected with the DroidDream malware, estimating that upwards of 30,000 users have downloaded at least one of the more than 30 infected apps. Google has removed the apps from the market.”
The user does NOT have to run the application to trigger the data theft. A phone call can trigger that event by invoking android.intent.action.PHONE_STATE intent (an incoming phone call). When that occurs data is extracted from the phone and sent to a remote site including IMEI, IMSI, installed package list, other data and possibly install other applications.
Additionally mylookout.com a company that makes smart phone security software posted a analysis of droiddreamlight and a set of infected applications here:
http://blog.mylookout.com/
ISC Site Redesign
Later today, we are going to roll out a redesign of the ISC website to bring it in line with the current design of www.sans.edu and to overall refresh the look of the site. If you see a problem, please let us know at handlers @ sans. edu, or if you can use the contact form, use it. Include a screen shot and your browser / OS version.
Update: the new design is live now (obviously...) if you have issues with the site, you can still use the old site at http://iscold.sans.edu for the next couple of weeks.
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Comments