The Risks of Remote Desktop for Access Over the Internet

It’s convenient to use the Remote Desktop Protocol (RDP) for accessing systems over the Internet, especially in server environments. However, exposing RDP to direct connections is risky. This setup not only gives remote attackers the opportunity to guess logon credentials, but also relies on the lack of a remotely-exploitable vulnerability in Microsoft’s RDP implementation.

Microsoft’s Security Bulletin MS12-020, released in March 2012, described critical vulnerability in Microsoft’s RDP implementation on most Windows platforms (CVE-2012-0002). This bug could allow a remote unauthenticated attacker to run arbitrary code on the affected system by sending “a sequence of specially crafted RDP packets.”

Microsoft provides a detailed perspective on the CVE-2012-0002 vulnerability in its Security Research & Defense blog, stating that even though it has no knowledge of the corresponding exploits, it believes that “an exploit for code execution will be developed in the next 30 days.”

I suspect such an exploit will appear sooner than 30 days, because of the relatively fast techniques available to attackers for reverse-engineering a patch to understand the nature of the vulnerability they need to target. Such an exploit would provide an attacker with access to targeted server environments and would enable automated opportunistic break-ins into servers and workstations that expose RDP to the Internet. Such an exploit would also be effective as part of a network worm for automated propagation across vulnerable systems.

My recommendations for handling the CVE-2012-0002 RDP vulnerability and future risks related to RDP:

• Understand what systems in your environment expose RDP to the Internet. Create a plan to apply the MS12-020 as soon as practical.
• Change the port on which your systems listen for RDP connection to avoid using the default TCP port 3389. Automated scanners and worms will be less likely to locate your RDP listeners on high-non-standard ports.
• Consider configuring your RDP settings to use Enable Network Level Authentication (NLA) on Windows Vista and later platforms, as suggested by Microsoft.
• Remember to have strong authentication for systems utilizing RDP to deal with remote password-guessing attacks.

— Lenny Zeltser

3 Free Tools to Fake DNS Responses for Malware Analysis

When analyzing malware using behavioral techniques, it’s often useful to intercept network connections in your lab. Since malicious software commonly uses hostnames when communicating with network resources, you can redirect such connections by defining the desired hostname to IP address mapping. Here are 3 free tools that can make it easy to accomplish this.

Rather than providing the malicious program the IP address of the actual host it’s trying to access, you can provide the IP address of an internal laboratory system. It’s possible to define this mapping in the “hosts” file on the infected laboratory computer. Alternatively, you can use a DNS server provide falsified DNS responses to queries. If you don’t want to configure a full-blown DNS server, you can use specialized tools such as ApateDNS, FakeDNS and fakeDNS.py.

ApateDNS in Action on Windows

Mandiant recently released a Windows tool called ApateDNS, written by Steve Davis. ApateDNS’s DNS responses will specify the desired IP address of your choosing, regardless of which hostname is being resolved. The tool logs all DNS queries it processes.

To use ApateDNS, you’ll need to point your infected laboratory system to the host where ApateDNS is running. In most scenarios, though, you’ll probably run ApateDNS directly on the infected host. While the tool attempts to automatically configure your local system to use localhost as the DNS server while ApateDNS is running, this doesn’t always work; be prepared to manually modify your DNS settings for this purpose.

FakeDNS in Action on Windows

FakeDNS is a free Windows tool from Verisign’s iDefense group, which is part of the larger Malcode Analysis Pack distribution. Though the original Malcode Analysis Pack web page is no longer accessible, you can still download the executable’s installer file from the iDefense website.

Like ApateDNS, FakeDNS responds to all DNS queries with the specified IP address, logging the details of the received requests and transmitted responses.

fakedns.py in Action on Linux

Another option for falsifying DNS responses in a malware analysis lab is the fakedns.py script by Francisco Santos. It’s written in Python, and will run on most platforms as long as Python is installed on the system. A version of this script is included in the REMnux Linux distribution.

The fakedns.py script is a command-line tool. By default, it will respond to DNS queries with the IP address of the host where the script is running, but this behavior can be modified using a command-line option.

To see how fake DNS servers can be used for malware analysis, take a look at my recorded Introduction to Malware Analysis webcast.

Hand-picked related posts:

• NetworkMiner for Analyzing Network Streams and Pcap Files
• Using Netsh for Easier Network Setup in a Malware Lab
• Process Monitor Filters for Malware Analysis and Forensics

— Lenny Zeltser

8 Reasons for Denial-of-Service (DoS) Attacks

Denial of Service attacks (DoS) affect numerous organizations connected to the Internet. They distrupt normal business operations, are practically impossible to prevent and are costly and time-consuming to handle. It pays to spend some time understanding the way a DoS inicident might affect your organization and how you might handle the situation.

One way to start thinking about your ability to withstand and respond to DoS attacks is to consider why such incidents occur. The common reasons include the following:

• Extortion via a threat of a DoS attack: The attacker might aim to directly profit from his perceived ability to disrupt the victim’s services by demanding payment to avoid the DoS attack.

• Turf wars and fights between online gangs: Groups and individuals in engaged on Internet-based malicious activities might use DoS as weapons against each others’ infrastructure and operations, catching legitimate businesses in the cross-fire.

• Anti-competition business practices: Cyber-criminals sometimes offer DoS services to take out competitor’s websites or otherwise disrupt their operations.

• Punishment for undesired actions: A DoS attack might aim to punish the victim for refusing an extortion demand or for causing disruption to the attacker’s business model (e.g., spam-sending operations)

• Expression of anger and criticism: Attackers might use the DoS attack as a way of criticizing the affected company for exhibiting undesirable political, economic or monetary behaviors.

• Training ground for other attacks: Attackers sometimes might target when fine-tuning DoS tools and capabilities for future attacks, which will be directed at other victims.

• Self-induced: Some downtime and service disruptions are the result of the non-malicious actions that the organization’s employees took by mistake.

• No apparent reason at all: Many victims never learn why they experienced a DoS attack.

Handling a DoS incident involves operating under stressful circumstances, often with limited resources and time. To learn how to prepare for dealing with a DoS attack and what to do if you’re caught unprepared, see my Network DDoS Incident Response Cheat Sheet.

— Lenny Zeltser

NetworkMiner for Analyzing Network Streams and Pcap Files

NetworkMiner is a free Windows utility for analyzing network traffic. It can examine live traffic that the system is sniffing off the wire. It can also explore contents of previously-captured traffic saved in the pcap format. The tool is designed to only display the details most relevant to network forensics. It is especially useful for carving packet captures to extract the files they contain, so you can further analyze the files that might be malicious.

One Use-Case for NetworkMiner

Consider a scenario where you’re analyzing a suspicious website, wishing to understand the way that it might try attacking its visitors. One way to approach this challenge is to browse the website using a Windows laboratory system designated for this type of work. In this case, your hope might be to have the system attacked and infected, so you can understand the nature of the threat.

There are several tools that could capture relevant details about the attack, so you can analyze them to understand what transpired. For instance, CaptureBAT can capture not only process-level activity on the laboratory system, but also create a pcap file of the observed network traffic. You can also run a dedicated network sniffer, such as tcpdump or Wireshark’s dumpcap, or use the sniffer built into NetworkMiner.

NetworkMiner in Action

For a quick demonstration of NetworkMiner, I’ll use the pcap file I created for the network forensics puzzle called Ms. Moneymany’s Mysterious Malware. (Though that context is over, you may want to download its files and experiment with them if you haven’t done so already.)

After you load the pcap file into NetworkMiner, it parses the file and presents several tabs with various aspects of the traffic and its contents. These include:

• The observed hosts, including their DNS names, IP addresses and ports used during the monitored period
• HTTP parameters sent to web servers as part of the observed session
• Clear-text ASCII contents extracted from the network streams, including a separate tab for any captured credentials
• The files exchanged between the hosts during the monitored period

NetworkMiner automatically carves out the files found in the network stream, saving them to a local folder. One of the reasons for using an dedicated laboratory system when using the tool in this capacity is that the files might be malicious, and you may get infected if you don’t handle them carefully.

To view the extracted file, right-click on the file of interest in NetworkMiner’s Files tab, then select open folder.

To experiment with the pcap file I mentioned in this write-up, read and consider solving the Ms. Moneymany’s Mysterious Malware network forensics puzzle. Also check out my follow-up malware analysis challenge. For more ways of using NetworkMiner, look over to the NETRESEC Network Security Blog.

Update: Though NetworkMiner is designed to work on Windows, you can get it to run on Linux, including BackTrack.

— Lenny Zeltser

VMware Network Isolation for a Malware Analysis Lab

When analyzing malware, it helps to have an isolated laboratory environment that you can infect with the malware sample to interact with it while learning about its capabilities. The lab typically involves several computer systems networked together. The computers can be physical boxes, but are often virtualized using tools such as VMware and VirtualBox for convenience and control purposes.

The Need for Isolating the Malware Analysis Laboratory

The analyst needs to put extra care to configure the lab in a way that minimizes the risk of the malicious program escaping onto the production network. For this reason, it’s not to connect the laboratory environment to the corporate networks. Extra care needs to be exercised when virtualizing the lab, not only because of the potential vulnerability that could allow an escape from the virtualized system, but also to account for possible configuration and user errors.

My earlier article described how to use VMware to build such as lab. There, I advised the use of the host-only networking option for interconnecting virtual systems using a simulated network without additional hardware. This setup works well; however, it has the weakness of allowing the physical host and virtualized systems to interact with each other through a virtual network adapter that VMware installs onto the physical host.

Defining a Dedicated Virtual Network

To exercise tighter control over the virtualized network of your lab when using VMware, consider creating a new virtual network for the virtualized systems, instead of using the default host-only network. If your physical host is running VMware Workstation on Windows, you can do this through the following steps:

1. Edit > Virtual Network Editor.
2. Pick a network that’s not being used, such as VMnet3. VMnet0, VMnet3 and VMnet8 are used by VMware by default, so I suggest not modifying them.)
3. Enable the “Use local DHCP service” if you’d like to use the DHCP service built into VMware. You’ll want to do this unless you have another DHCP service in the lab or plan to statically assign network configuration details to your virtualized systems.
4. Enable “Host-only” if it’s not already selected.
5. Disable “Connect a host virtual adapter to this network” if it’s not already deselected.
6. Click OK

The settings should look something like this:

Assigning the Dedicated Virtual Network

At this point the desired virtual network (VMnet3 in my example) should be ready for use. Now you need to configure your virtualized systems to use it. To do that, go to VM > Settings in each virtual machine, change the Network Adapter to use the Custom network connection and pick the desired network (i.e., VMnet3):

If your virtualized systems are configured to use DHCP, they should get the new network settings automatically after a reboot.

Hand-picked related posts:

• Using VMware for Malware Analysis
• 5 Steps to Building a Malware Analysis Toolkit Using Free Tools
• Using Free Windows XP Mode as a VMware Virtual Machine

— Lenny Zeltser

Common Failures of Information Security Tools (Part 1)

We’re used to thinking of medicine in terms of not only its healing power, but also its side effects. We recognize that even a substance designed to support health might affect the body in undesirable ways, especially when interacting with other drugs. This dynamic also applies to the measures we take to maintain and improve information security safeguards: it’s not uncommon for security technologies to have a negative on the environment being protected.

Let’s look at some examples of potential failures of information security tools, so we can anticipate and account for the problems:

• Traditional network firewalls are often blamed for performance and connectivity woes, since they regulate traffic that crosses network boundaries. A firewall rule set can be too open, allowing unnecessary traffic in and out of the environment. The situation that is noticed more often is when the rules are too tight, blocking applications’ components from communicating or preventing the users from accessing needed services.

• Web Application Firewalls (WAFs) typically implement more complex logic to distinguish between legitimate and malicious actions than traditional network firewalls. The protection tends to combine static rules with behavior-monitoring components; moreover, the rules are often customized for individual web applications and can become invalidated after the protected site is updated. For this reason, anticipating and troubleshooting WAF problems can be challenging. This is why organizations may hesitate when switching WAFs from monitoring-only to active blocking mode.

• Antivirus tools are arguably the most mature components of an information security infrastructure. The most common way in which they fail is by considering a malicious file to be benign. They can also sometimes flag legitimate files as malicious, which has been known to not only deny access to applications, but also crash systems. The likelihood of falsely flagging a normal file as malicious might be increasing, as antivirus vendors rely less on static signature-based detection and more on heuristic and behavioral techniques.

Do you have stories of network firewalls, WAFs and antivirus tools failing? Please share the side effects you’ve experienced in the comments to this post. I’d also love to hear your thoughts on mitigating the risks of such adverse reactions to introducing or updating security tools in an enterprise setting. We all have much to learn in this regard.

Continued in a follow-up post…

Related:

• Web Application Firewalls (WAFs) Will Be Ubiquitous
• Antivirus Products Are Like Cold Medicine - Not A Rant
• Pros and Cons of Virtual Patching to Address Vulnerabilities

— Lenny Zeltser

6 Ideas for a Protean Information Security Architecture

Proteus, a sea god, could change his shape to confuse adversaries and avoid capture. Thinking along these lines, I wonder how the security architecture of networks and applications might incorporate protean properties, making it harder (more expensive and time-consuming) for attackers to compromise our defenses?

An environment that often changes may be harder to attack, but it is also hard to manage. In fact, many vulnerabilities seem to be associated with our inability to securely and timely implement changes, such as deploying security updates or disabling unnecessary services.

To create a protean security architecture, we’ll need to think asymmetrically: what attributes can complicate attackers’ jobs more than they complicate the jobs of defenders? I am not sure how to do this, but I have a few ideas to get started:

• Open “fake” ports on your perimeter firewall using a script, so that an external attacker is misinformed about what services are accessible from the Internet. Redirect the connections to low-interaction honeypots.

• Rather than blocking or dropping traffic on the perimeter firewall, configure the device to send TCP packets that indicate a transmission error, making it hard for the attacker to distinguish between a bad connection and a blocked port.

• Deploy honeytokens on your web server to mimic the appearance of web applications that aren’t actually installed there. This may stall and misdirect the attacker. Vary the type and location of the tokens periodically.

• Mimic the appearance of Internet-accessible servers that seem to be accessible via protocols such as SSH by using honeypots (e.g., Kippo). This can slow down and misdirect the attacker.

• Set up a DNS blackhole to redirect internal infected systems to websites that aren’t actually malicious by using a tool such as DNS Sinkhole. You can use a honeypot such as Dionaea to further learn about malware.

• Use open cloud services to bring up irrelevant web and other servers that seem to be associated with your organization, but don’t host sensitive data. Periodically decommission them and bring up new ones.

My ideas seem to be gravitating towards using honeypots to implement an element of deception, but there should be other ways of creating an infrastructure that is changing slightly to confuse or misdirect attackers and their tools. Do you have any ideas?

Proteus eventually captured by Menelaus, who found a way of ambushing Proteus and chaining him down. (Menelaus had an insider’s help, having received a tip from Idothea—Proteus’ daughter.) So a protean approach to defense isn’t foolproof—it is one of the elements we may be able to incorporate into an information security architecture to strengthen our resistance to attacks.

Update: For good thoughts on the topic, see Mike Rothman’s post HoneyClouds and the Confusion Control.

Related:

• Reflections Upon Deception and Protean Security Tactics
• Honeypots as Part of a Modern IT Infrastructure
• Deception Lessons for Information Security from World War II

— Lenny Zeltser

Deception Lessons for Information Security from World War II

I’ve been thinking about the role that deception can play in information security. Honeypots present an example of how data defenders can mislead or slow down attackers. Similarly, attackers can deceive defenders. For example, Nmap can spoof source IP addresses of network-scanning packets, so defenders have a hard time determining the true origin of the probes.

I stumbled upon a facinating paper by Donald J. Bacon titled Second World War Deception: Lessons Learned for Today’s Joint Planner (PDF). Among its many examples, the paper mentions two types of deception operations employed by Allied Forces to confuse and misdirect the German military during World War II:

• Ambiguity-type deception operations “created uncertainty and inhibited accurate intelligence assessments, resulting in a German misallocation of forces.”
• Misleading-type deception operations aimed at reducing ambiguity by “building up the attractiveness of one wrong alternative.”

The Allies were able to use deception to gain “surprise for offensive operations and to provide increased security for forces by masking military objectives, planning, preparations, and operations.”

The paper also mentions that Soviet military’s deception efforts during World War II were used primarily to “conceal large troop movements and concentrations to attain surprise for offenses.” The Soviets’ greatest victories in the war can be traced to their success at fully integrating deception “into their operational planning and execution. The result was the Germans often knew only the frontline Soviet troop dispositions—everything behind the front line was a ‘blur.’”

The paper quotes historian Charles Cruickshank, highlighting a critical aspect of successful deception:

“The perfect deception plan is like a jigsaw puzzle. Pieces of the information are allowed to reach the enemy in such a way as to convince him that he has discovered them by accident.”

One of my take-aways from this paper is that deception efforts cannot be one-off projects. To be successful, they have to be centrally managed and integrated into the fabric of operations. This is why the use of deception might only be practical for mature and well-funded parties.

To what extent can deception be used as part of offensive and defensive information security operations? The efforts by the Honeynet Project have been instrumental at helping the infosec industry figure this out. I suspect there’s much more for us to learn about using deception to detect and resist network-based attacks.

— Lenny Zeltser