(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 

Enlarge (credit: Tavis Ormandy)

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:

Read 6 remaining paragraphs | Comments

 
 

=============== 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 [1].

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.

[1] https://bugs.chromium.org/p/project-zero/issues/detail?id=1096

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
 

Enlarge (credit: portal gda)

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.

Read 7 remaining paragraphs | Comments

 
Linux Kernel CVE-2017-5551 Local Denial of Service Vulnerability
 
Linux Kernel CVE-2017-5550 Local Information Disclosure Vulnerability
 
Linux Kernel CVE-2017-5549 Local Denial of Service Vulnerability
 
Linux Kernel CVE-2017-5546 Local Denial of Service Vulnerability
 
Linux Kernel CVE-2016-10153 Local Denial of Service Vulnerability
 
Linux Kernel CVE-2016-10154 Local Denial of Service Vulnerability
 
Linux Kernel CVE-2017-5548 Local Denial of Service Vulnerability
 
APPLE-SA-2017-01-23-6 iCloud for Windows 6.1.1
 
APPLE-SA-2017-01-23-3 watchOS 3.1.3
 
APPLE-SA-2017-01-23-2 macOS 10.12.3
 

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. [1] And well, this also makes good material for my IPv6 class [2]. 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:

I=IPv6(dst=2001:db8::1)ICMP=ICMPv6EchoRequest(data=A*1000)FH=IPv6ExtHdrFragment()packets=fragment6(I/FH/ICMP,100)

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)

[1] https://tools.ietf.org/html/rfc8021
[2] https://www.sans.org/course/ipv6-essentials

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
Linux Kernel CVE-2017-5547 Local Denial of Service Vulnerability
 
APPLE-SA-2017-01-23-5 Safari 10.0.3
 
APPLE-SA-2017-01-23-4 tvOS 10.1.1
 
PHP 'process_nested_data()' Incomplete Fix Use After Free Remote Code Execution Vulnerability
 
FiberHome Fengine S5800 Switches CVE-2017-5544 Denial of Service Vulnerability
 
b2evolution CVE-2017-5553 Cross Site Scripting Vulnerability
 
LibTIFF CVE-2017-5563 Heap Based Buffer Overflow Vulnerability
 
OnePlus 3 and 3T CVE-2017-5554 Local Denial of Service Vulnerability
 
ESA-2016-150: RSA® Security Analytics Reflected Cross-Site Scripting Vulnerability
 
ESA-2016-146: EMC Avamar Data Store and Avamar Virtual Edition Privilege Escalation Vulnerability
 
Libimobiledevice Libplist 'plistutil.c' Heap Buffer Overflow Vulnerability
 
Red Hat JBoss Enterprise Application Platform CVE-2016-8627 Remote Denial of Service Vulnerability
 
GeniXCMS CVE-2017-5575 SQL Injection Vulnerability
 
b2evolution Incomplete Fix CVE-2017-5539 Directory Traversal Vulnerability
 
Apache Tomcat CVE-2016-6817 Denial of Service Vulnerability
 
Brocade Network Advisor CVE-2016-8205 Directory Traversal Vulnerability
 
Brocade Network Advisor CVE-2016-8204 Directory Traversal Vulnerability
 
Microsoft Remote Desktop Client for Mac Remote Code Execution - Update
 
Adobe Acrobat and Reader APSB17-01 Multiple Heap Buffer Overflow Vulnerabilities
 
Brocade Network Advisor CVE-2016-8206 Directory Traversal Vulnerability
 
Adobe Acrobat Extension for Chrome CVE-2017-2929 Cross Site Scripting Vulnerability
 
VLC Media Player CVE-2016-5108 Arbitrary Code Execution Vulnerability
 
xdelta3 CVE-2014-9765 Local Buffer Overflow Vulnerability
 
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
NTOPNG Web Interface v2.4 CSRF Token Bypass
 
Executable installers are vulnerable^WEVIL (case 46): Pelles C allows arbitrary code execution
 
[SECURITY] [DSA 3769-1] libphp-swiftmailer security update
 
[SECURITY] [DSA 3770-1] mariadb-10.0 security update
 
Internet Storm Center Infocon Status