CSAM! Send us your logs!

Published: 2013-10-01. Last Updated: 2013-10-01 20:01:35 UTC
by Adrien de Beaupre (Version: 1)
0 comment(s)

Today is the beginning of Cyber Security Awareness Month. Apparently the month's official theme is "Our Shared Responsibility," We at the SANS Internet Storm Center want your logs! Send us packets, malware, all your logs, log snippets, observations, things that go bump on the 'net, things that make you go HMMMM, or just send us email to discuss InfoSec. What can we do as individuals to increase information security and encourage secure practices among co-workers, friends, and family? Let us know via our Contact Us page, or the comments below.

This year our theme is 'wierd. wonderful, and interesting stuff in logs'. In past years here have been some of our themes:

https://isc.sans.edu/tag.html?tag=Cyber%20Security%20Awareness%20Month%202010 - awareness
https://isc.sans.edu/tag.html?tag=Cyber%20Security%20Awareness%20Month%202011 - critical controls
https://isc.sans.edu/tag.html?tag=Cyber%20Security%20Awareness%20Month%202012 - theme was "standards"

You can watch NCSAM in the USA go live at the following Facebook URI: https://www.facebook.com/staysafeonline/app_142371818162
 

Let's be careful out there!

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
My SANS Teaching Schedule

0 comment(s)

*Metaspoit Releases Module to Exploit Unpatched IE Vuln CVE-2013-3893

Published: 2013-10-01. Last Updated: 2013-10-01 19:57:14 UTC
by John Bambenek (Version: 2)
0 comment(s)

Metasploit has just released a module to exploit the currently unpatched CVE-2013-3893 vulnerability in Internet Explorer.  This vulnerability can be used for remote code execution if you can get a user to go to a specifically crafted webpage.  Microsoft has released a FixIt that should be deployed for this vulnerability for 32-bit versions of IE.  EMET is also available as a mitigating control.

With a metasploit module out there, we can now expect commodity exploitation out there available to the low-rent script kiddie community.

See our previous handlers diary on the subject by Russ McRee here.

UPDATED 2000 UTC by John Bambenek: Threatpost has three different attacks using the IE vulnerability which will widen the field of tools used.

--
John Bambenek
bambenek \at\ gmail /dot/ com
Bambenek Consulting

0 comment(s)
Google Chrome updated, over 50 security fixes http://googlechromereleases.blogspot.com/

iOS 7 Adds Multipath TCP

Published: 2013-10-01. Last Updated: 2013-10-01 12:55:28 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)
iOS 7 added a new feature, that hasn't been widely advertised. This feature, Multi Path TCP (MPTCP) is currently used by Siri, but could be used by other applications down the road. MPTCP is an extension to TCP allowing a TCP connection between hosts using multiple IP addresses. It's design is in particularly interesting in that it is backwards compatible with firewalls. As far as your firewall or other network devices are concerned, each multipath TCP connection is a valid TCP connection using it's own sequence numbers and its own handshake to set it up and tear it down. All the "magic" of signaling happens via new TCP options.
 
MPTCP is not proprietary. It is a standard (RFC 6824 [1]), and has been implemented for Linux for example, but so far has not seen much use, which may cause you to notice it the first time when looking at traffic from iOS 7 devices.
 
Just as a quick refresher: A TCP connection is established by the client sending a SYN packet to the server. The server responds with a SYN-ACK and the client completes the handshake using an ACK packet. During this handshake, the hosts will exchange random initial sequence numbers. The sequence number will increment by one for each byte transmitted. The sequence number is very important to reassemble the data stream. Without sequence number, the data stream could loose it's order.
 
Simplistically, one could setup two TCP connections, and just distribute the data between them. But if the sequence number stream is not continuous, many firewalls will disrupt the connection. This is why each MPTCP stream has its own sequence number. But this puts up another problem: How do we know how the streams, or "subflows" as the RFC calls them, fit together?
 
Lets first talk about how the MPTCP connection is setup:
 
The TCP connection starts out like any TCP connections with a SYN/SYN-ACK/ACK handshake. However, if MPTCP is available, the three handshake packets will include the "Multipath Capable (MP_CAPABLE)" option. Both ends need to support multipath, or it will not be used. The MP_CAPABLE option includes a key, that will later be used to authenticate additional subflows.

A host may now add a new subflow, and this subflow will be authenticated using a hash derived from the keys exchanged earlier, and nonces that are unique to each new subflow. The MP_JOIN option is used to carry this data. Throughout the connection, hosts may inform each other of newly acquired addresses and they may use the for new subflows. Since each subflow has its own set of sequence numbers, "Data Sequence Signals" are used to communicate how the sequence numbers in the subflow map to the combined data flow. The protocol has a lot of little details that make it well suited for hosts connected to multiple wireless networks. For example, different subflows may have different priorities. One usage scenario is a cell phone connected to a Wifi as well as a cellular network, and roaming between the two. For example, you start a TCP connection at home, and continue using it as you leave the house and your phone switches to the cellular network. As long as both networks are available for a while, MPTCP may drop the Wifi connection and exclusively use the cell phone data connection until you reach another WiFi network. But enough about how the protocol works, here are some packets. A quick BPF to capture these packets (for example with tcpdump):

tcp[12]&0xf0=>0xe0

It is not perfect, but because the options involved are rather large, you will find MPTCP packets by looking for larger TCP header sizes. This filter looks for a header size of 56 and above, with 60 being the maximum (you don't really need the bitmask for the filter). Wireshark and tshark deal rather well with MPTCP. For example, tshark displays for the TCP options:

        Multipath TCP: Multipath Capable
            Kind: Multipath TCP (30)
            Length: 12
            0000 .... = Multipath TCP subtype: Multipath Capable (0)
            .... 0000 = Multipath TCP version: 0
            Multipath TCP flags: 0x01
                0... .... = Checksum required: 0
                .... ...1 = Use HMAC-SHA1: 1
            Multipath TCP Sender's Key: 8848941202347829228
tcpdump on the other hand has a much harder time:

16:44:15.681318 IP 70.91.145.11.57799 > 17.174.8.5.443: Flags [S], seq 847601216, win 65535, options [mss 1460,nop,wscale 3,Unknown Option 3000017acdc123cc42a7ec,nop,nop,TS val 102569696 ecr 0,sackOK,eol], length 0

it just displays the raw option as an "Unknown Option" Option "0x30" happens to be the "Multipath Capable" option.
 
Other options:
0x31: MP_JOIN
0x32: DSS - Data Sequence Signal
0x33: ADD_ADDR - Add new address
0x34: REMOVE_ADDR - Remove address
0x35: MP_PRIO - Change subflow priority
0x36: MP_FAIL - Fallback (used to communicate checksum failures back to sender)
0x37: MP_FASTCLOSE - Fast Close (like TCP Reset, but only for subflow)
 
[1] http://tools.ietf.org/html/rfc6824

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: iOS MPTCP siri TCP
4 comment(s)
ISC StormCast for Tuesday, October 1st 2013 http://isc.sans.edu/podcastdetail.html?id=3572

Comments


Diary Archives