Information Security News
The Chrome browser extension for Cisco Systems WebEx communications and collaboration service was just updated to fix a vulnerability that leaves all 20 million users susceptible to drive-by attacks that can be carried out by just about any website they visit.
A combination of factors makes the vulnerabilities among the most severe in recent memory. First, WebEx is largely used in enterprise environments, which typically have the most to lose. Second, once a vulnerable user visits a site, it's trivial for anyone with control of it to execute malicious code with little sign anything is amiss. The vulnerability and the resulting patch were disclosed in a blog post published Monday by Tavis Ormandy, a researcher with Google's Project Zero security disclosure service.
Martijn Grooten, a security researcher for Virus Bulletin, told Ars:
=============== Rob VandenBrink Metafore(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
The Google 0-Day project announced a critical remote code execution vulnerability in Ciscos WebEx plugin for Google Chrome. This vulnerability allows a remote attacker to execute arbitrary code on the victims system by delivering it to the WebEx plugin via a special secret URL.
The secret pattern: cwcsf-nativemsg-iframe-43c85c0d-d633-af5e-c056-32dc7efc570b.html
Google set up a test page and published a detailed report about how this vulnerability can be used to execute code .
Note that version 1.0.3 of the plugin, which was released on Sunday (Jan 22nd), appears to be still vulnerable. At this point, it is probably best to uninstall the plugin and use a different browser for WebEx (of course, this issue may affect plugins for other browsers as well).
An attack would be invisible to the userif executed right. The user does not have to willingly join a WebEx meeting to exploit this vulnerability.
A virulent family of malware that infected more than 10 million Android devices last year has made a comeback, this time hiding inside Google Play apps that have been downloaded by as many as 12 million unsuspecting users.
HummingWhale, as the professionally developed malware has been dubbed, is a variant of HummingBad, the name given to a family of malicious apps researchers documented in July invading non-Google app markets. HummingBad attempted to override security protections by exploiting unpatched vulnerabilities that gave the malware root privileges in older versions of Android. Before Google shut it down, it installed more than 50,000 fraudulent apps each day, displayed 20 million malicious advertisements, and generated more than $300,000 per month in revenue. Of the 10 million people who downloaded HummingBad-contaminated apps, an estimated 286,000 of them were located in the US.
HummingWhale, by contrast, managed to sneak its way into about 20 Google Play apps that were downloaded from 2 million to 12 million times, according to researchers from Check Point, the security company that has been closely following the malware family for almost a year. Rather than rooting devices, the latest variant includes new virtual machine techniques that allow the malware to perform ad fraud better than ever, company researchers said in a blog post published Monday.
I may extend this with a second entry later this week. But as so often, I found myself on a long flight with some time on my hands, and since the IETF just released a new RFC regarding IPv6 atomic fragments, I figured I will play a bit with scapy to kill time.  And well, this also makes good material for my IPv6 class . This is supposed to entice you to play and experiment. Let me know if you find anything neat.
Fragmentation is a necessary evil of packet networking. Packets will encounter networks with different MTUs as they traverse the network, and even if all of your networks have the same MTU, it may not be large enough to accommodate some packets (for example large DNS replies taking advantage of EDNS0).
IPv6 made some substantial changes to the way packets are fragmented. The goal was to simplify and even discourage fragmentation, and also to remove some of the work involved from routers. As a result, only the source of the packet is supposed to fragment, not the router. This will not only make live easier for routers, but it also allows senders to adjust the packet size appropriately and forego fragmentation. Double fragmentation, where two routers fragment already fragmented packets further, should no longer happen. This double fragmentation was one source of a lot of pain for IPv4. To further reduce the probability of having to fragment packets, IPv6 defines a minimum MTU of 1280. Networks with an MTU of less than 1280 bytes will no longer be able to route IPv6 traffic.
But what does this mean for network traffic, how is this implemented, and how do I test implementations? In short: scapy-)
1 - What happens to fragments that are smaller than 1280 bytes (and not the last fragment)?
For all of our tests, we use simple echo requests. To build them in scapy:
This creates a set of packets that should never be seen via IPv6. But, after sending it with:
for p in packets: send(p)
We see in tcpdump that this works quite well:
IP6 2001:db8::2 2001:db8::1: frag (0|48) ICMP6, echo request, seq 0, length 48IP6 2001:db8::2 2001:db8::1: frag (48|48)IP6 2001:db8::2 2001:db8::1: frag (96|48)....IP6 2001:db8::2 2001:db8::1: frag (960|48)IP6 2001:db8::1 2001:db8::2: ICMP6, echo reply, seq 0, length 1008
The recipient replies as expected with a non-fragmented packet.
2 - What happens if a Packet Too Large error comes back with an MTU of less than 1280 Bytes?
Now lets up this by a step. I will now send the same echo request packet without fragmenting it. Of course, we will get a reply, but my host will respond with a Packet too large, Fragmentation Required error and advertise the ridiculous small MTU of 100 bytes, which is small even for IPv4. The reason that I am doing it this way is so that I can send all the crafted packets from one host:
send(I/ICMP)IP6 2001:db8::2 2001:db8::1: ICMP6, echo request, seq 0, length 1008IP6 2001:db8::1 2001:db8::2: ICMP6, echo reply, seq 0, length 1008send(I/ICMP)send(I/ICMPv6PacketTooBig(mtu=100))/send(I/ICMP)IP6 2001:db8::2 2001:db8::1: ICMP6, echo request, seq 0, length 1008IP6 2001:db8::1 2001:db8::2: ICMP6, echo reply, seq 0, length 1008IP6 2001:db8::2 2001:db8::1: ICMP6, packet too big, mtu 100, length 8IP6 2001:db8::2 2001:db8::1: ICMP6, echo request, seq 0, length 1008IP6 2001:db8::1 2001:db8::2: ICMP6, echo reply, seq 0, length 1008
ICMP error messages need to include parts of the packet that caused them to be taken serious. So we need to capture the ICMP echo response, and append it to the error:
r=sr1(I/ICMP)send(I/ICMPv6PacketTooBig(mtu=100)/r)send(I/ICMP)IP6 2001:db8::2 2001:db8::1: ICMP6, echo request, seq 0, length 1008IP6 2001:db8::1 2001:db8::2: ICMP6, echo reply, seq 0, length 1008IP6 2001:db8::2 2001:db8::1: ICMP6, packet too big, mtu 100, length 1056IP6 2001:db8::2 2001:db8::1: ICMP6, echo request, seq 0, length 1008IP6 2001:db8::1 2001:db8::2: frag (0|1008) ICMP6, echo reply, seq 0, length 1008
Now we get a rather strange ICMP echo reply in the end. It is actually standard compliant, and referred to as an atomic fragment. The packet includes a fragmentation header, but isnt really fragmented. The offset is 0, the more fragment flag is cleared, and well, the packet still carries the full 1008 bytes IP payload (it is actually 8 bytes longer now with the fragment header). The idea here is that the small packet too big message came likely from a tunnel, and that the packet will be fragmented over IPv4. Adding the IPv6 fragment header provides the tunnel endpoint with a fragment ID to derive an IP ID from. Odd.. but well, the RFC tells us to do this.
These atomic fragments have been noted to lead to possible DoS conditions if we receive two of them (one of them spoofed). This would represent an overlapping fragment, and then both will get dropped.
3 - Are overlapping fragments still an issue?
For IPv6, overlapping fragments need to be dropped. But are they? Creating them is a bit tricky. We need to get the protocol checksum right for the after re-assembly packet, which of course is ambiguous. In IPv4, we were able to cheat with UDP packets. So far, I havent been able to find a set of packets / operating system combination that violates the RFC. Here is a sample scapy script to create these packets. It avoids the checksum issue by just using a static payload throughout the packet. And since we do not get an answer for the ICMP echo request, the question of reassemble preference doesnt come up.
#!/usr/bin/pythonfrom scapy.all import *dst=2001:db8::1fid=random.randint(0,100000)I=IPv6(dst=dst,nh=44)ICMP=ICMPv6EchoRequest(data=x*104,cksum=0x2de5)FH=IPv6ExtHdrFragment(nh=0x3a,offset=0,m=1,id=fid)send(I/FH/ICMP)FH=IPv6ExtHdrFragment(nh=0x3a,offset=13,m=0,id=fid)send(I/FH/xxxxxxx)