Exploit This

Security News, Exploits, and Vulnerabilities.

The Shade Encryptor: a Double Threat

A family of ransomware Trojans emerged in late 2014/early 2015, and quickly established itself among the top three most widespread encryptors. This threat has been assigned the verdict Trojan-Ransom.Win32.Shade according to Kaspersky Lab’s classification. The original name given to the encryptor by its creator is not known.

Tracking a Bluetooth Skimmer Gang in Mexico

-Sept. 9, 12:30 p.m. CT, Yucatan Peninsula, Mexico: Halfway down the southbound four-lane highway from Cancun to the ancient ruins in Tulum, traffic inexplicably slowed to a halt. There was some sort of checkpoint ahead by the Mexican Federal Police. I began to wonder whether it was a good idea to have brought along the ATM skimmer instead of leaving it in the hotel safe. If the cops searched my stuff, how could I explain having ultra-sophisticated Bluetooth ATM skimmer components in my backpack?

Ex-Ashley Madison CTO Threatens Libel Suit

Last month, KrebsOnSecurity posted an exclusive story about emails leaked from AshleyMadison that suggested the company’s former chief technology officer Raja Bhatia hacked into a rival firm in 2012. Now, an attorney for the former executive is threatening a libel lawsuit against this author unless the story is retracted.

Satellite Turla: APT Command and Control in the Sky

When you are an APT group, you need to deal with the constant seizure and takedown of C&C domains and servers. Some of the most advanced threat actors have found a solution — the use of satellite-based Internet links. In the past, we’ve seen three different actors using such links to mask their operations. The most interesting and unusual of them is the Turla group.

Attacking Diffie-Hellman protocol implementation in the Angler Exploit Kit

In Angler, threat actors used the Diffie-Hellman protocol to creating difficulties in firewall detection of the exploit and also making it harder for the analysts to get the exploit code. However, the experts from Kaspersky Lab managed to perform a successful attack against Diffie-Hellman protocol implementation and decipher the shellcode.

Our Fifth Latin American Security Analysts Summit in Santiago de Chile

Another memorable installment of the Latin American Security Analysts Summit has come and gone! This time it was held in the exquisite city of Santiago de Chile, where journalists from all over the region were greeted by Kaspersky Lab’s research team for two full days of knowledge and a little bit of leisure.

TGIF(P) – Thank god it’s fried phish

There is that expression “TGIF” and I recently noticed that some of my Japanese colleagues/friends would not know what it actually stands for. Spoiler: It commonly means “Thank god it’s Friday” and probably many working people will be able to… Read Full Article

Like Kaspersky, Russian Antivirus Firm Dr.Web Tested Rivals

A recent Reuters story accusing Russian security firm Kaspersky Lab of faking malware to harm rivals prompted denials from the company’s eponymous chief executive — Eugene Kaspersky — who called the story “complete BS” and noted that his firm was a victim of such activity. But according to interviews with the CEO of Dr.Web — Kaspersky’s main competitor in Russia — both companies experimented with ways to expose antivirus vendors who blindly accepted malware intelligence shared by rival firms.

Taking A Break From Research To Accelerate Startups: SSC 2015

How would you describe the best job in the world of security research? Would it be to work at the forefront of security research, diving into the bits and bytes of advanced malware and global threats, or to have a… Read Full Article

TA15-240A: Controlling Outbound DNS Access

Original release date: August 28, 2015

Systems Affected

Networked systems

Overview

US-CERT has observed an increase in Domain Name System (DNS) traffic from client systems within internal networks to publically hosted DNS servers. Direct client access to Internet DNS servers, rather than controlled access through enterprise DNS servers, can expose an organization to unnecessary security risks and system inefficiencies. This Alert provides recommendations for improving security related to outbound DNS queries and responses.

Description

Client systems and applications may be configured to send DNS requests to servers other than authorized enterprise DNS caching name servers (also called resolving, forwarding or recursive name servers). This type of configuration poses a security risk and may introduce inefficiencies to an organization.   

Impact

Unless managed by perimeter technical solutions, client systems and applications may connect to systems outside the enterprise’s administrative control for DNS resolution. Internal enterprise systems should only be permitted to initiate requests to and receive responses from approved enterprise DNS caching name servers. Permitting client systems and applications to connect directly to Internet DNS infrastructure introduces risks and inefficiencies to the organization, which include:

  • Bypassed enterprise monitoring and logging of DNS traffic; this type of monitoring is an important tool for detecting potential malicious network activity.
  • Bypassed enterprise DNS security filtering (sinkhole/redirect or blackhole/block) capabilities; this may allow clients to access malicious domains that would otherwise be blocked.
  • Client interaction with compromised or malicious DNS servers; this may cause inaccurate DNS responses for the domain requested (e.g., the client is sent to a phishing site or served malicious code).
  • Lost protections against DNS cache poisoning and denial-of-service attacks. The mitigating effects of a tiered or hierarchical (e.g., separate internal and external DNS servers, split DNS, etc.) DNS architecture used to prevent such attacks are lost.  
  • Reduced Internet browsing speed since enterprise DNS caching would not be utilized.

Solution

Implement the recommendations below to provide a more secure and efficient DNS infrastructure. Please note that these recommendations focus on improving the security of outbound DNS query or responses and do not encompass all DNS security best practices.  

  • Configure operating systems and applications (including lower-tier DNS servers intended to forward queries to controlled enterprise DNS servers) to use only authorized DNS servers within the enterprise for outbound DNS resolution.
  • Configure enterprise perimeter network devices to block all outbound User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) traffic to destination port 53, except from specific, authorized DNS servers (including both authoritative and caching/forwarding name servers).  
    • Additionally, filtering inbound destination port 53 TCP and UDP traffic to only allow connections to authorized DNS servers (including both authoritative and caching/forwarding name servers) will provide additional protections. 
  • Refer to Section 12 of the NIST Special Publication 800-81-2 for guidance when configuring enterprise recursive DNS resolvers. [1]

References

Revision History

  • August 28, 2015: Initial Release

This product is provided subject to this Notification and this Privacy & Use policy.

%d bloggers like this: