VMware Security Advisory: VMSA-2009-0015

Published: 2009-10-27
Last Updated: 2009-10-27 21:34:53 UTC
by Lenny Zeltser (Version: 1)
0 comment(s)

VMware released security advisory VMSA-2009-0015 today, announcing patches that resolve two security issues with some versions of VMware Workstation, Player, ACE, Server, Fusion, ESXi and ESX products. For details, see:

http://lists.vmware.com/pipermail/security-announce/2009/000069.html

-- Lenny

Lenny Zeltser - Security Consulting
Lenny teaches malware analysis at SANS. You're welcome to follow him on Twitter. You can also track new Internet Storm Center diaries by following ISC on Twitter.

Keywords:
0 comment(s)

Cyber Security Awareness Month - Day 27 - Active Directory Ports

Published: 2009-10-27
Last Updated: 2009-10-27 19:00:53 UTC
by Lenny Zeltser (Version: 1)
1 comment(s)

In the series of posts this month we've been looking at network ports relevant to security administrators. This note explores the ports used for Active Directory (AD) communications, which is a topic particularly relevant for allowing AD traffic across a firewall. For instance, you may be wondering which ports to open to allow AD replication across internal subnets, or to allow an AD member server on a screened subnet to authenticate to a domain controller on another subnet.

AD-Related Ports

Active Directory communications involve a number of ports, some of which are more familiar to network and security administrators than others. These were outlined in the Active Directory Replication over Firewalls article by Steve Riley:

  • RPC endpoint mapper: port 135 TCP, UDP
  • NetBIOS name service: port 137 TCP, UDP
  • NetBIOS datagram service: port 138 UDP
  • NetBIOS session service: port 139 TCP
  • SMB over IP (Microsoft-DS): port 445 TCP, UDP
  • LDAP: port 389 TCP, UDP
  • LDAP over SSL: port 636 TCP
  • Global catalog LDAP: port 3268 TCP
  • Global catalog LDAP over SSL: port 3269 TCP
  • Kerberos: port 88 TCP, UDP
  • DNS: port 53 TCP, UDP
  • WINS resolution: port 1512 TCP, UDP
  • WINS replication: 42 TCP, UDP
  • RPC: Dynamically-assigned ports TCP, unless restricted

For a full listing of AD-related services, see Microsoft's support article 832017 Service Overview and Network Port Requirements for the Windows Server System.

Which of these ports actually need to be allowed through the firewall depends on the scenario you're implementing and on your environment. For instance, support for NetBIOS services may unnecessary in situations where you have newer Windows systems supporting the SMB over IP protocol. Similarly, newer Windows environments make use DNS, instead of Windows for name resolution.

AD Replication

The ports that need to be open to facilitate cross-firewall AD replication differ, depending on the versions of Microsoft Windows in your environment. Microsoft provides OS-specific guidelines in its Active Directory and Active Directory Domain Services Port Requirements article. For instance, replication between servers that use Windows 2000 or 2003 require the following ports open bidirectionally on the firewall that's between the servers:

  • RPC endpoint mapper: port 135 TCP
  • LDAP: port 389 TCP, UDP
  • LDAP over SSL: port 636 TCP
  • Global catalog LDAP: port 3268 TCP
  • Global catalog LDAP over SSL: port 3269 TCP
  • DNS: port 53 TCP, UDP
  • Kerberos: port 88 TCP, UDP
  • SMB over IP (Microsoft-DS): port 445 TCP
  • RPC: Dynamically-assigned ports TCP, unless restricted  

To restrict the use of RPC ports, follow instructions in Microsoft's support article 224196 Restricting Active Directory Replication Traffic and Client RPC Traffic to a Specific Port and a TechNet blog entry Dynamic Client Ports in Windows Server 2008 and Windows Vista.

Authentication to AD

AD uses the following ports to support user and computer authentication, according to the Active Directory and Active Directory Domain Services Port Requirements article:

  • SMB over IP (Microsoft-DS): port 445 TCP, UDP
  • Kerberos: port 88 TCP, UDP
  • LDAP: port 389 UDP
  • DNS: port 53 TCP, UDP
  • RPC: Dynamically-assigned ports TCP, unless restricted  

Tunneling AD Traffic Using IPSec

If you don't like having to open this many ports, you could use IPSec to tunnel the traffic across the firewall. You could use ESP with encryption disabled, so the packets would still be cryptographically  signed and tunneled, but your intrusion detection systems (IDS) would still have visibility into the traffic.

Jason Fossen, who teaches the Securing Windows class at SANS, shared with us additional insights regarding the use of IPSec:

Because IPSec connections can be limited to those users and computers in specified global groups, is tightly integrated into the host-based Windows Firewall (which would be configured on all DMZ servers and participating controllers), and can optionally be tied into a Network Access Protection (NAP) infrastructure, the use of IPSec can provide benefits the perhaps outweigh the IDS/IPS hassles.

The Use of AD in the DMZ or a Screened Subnet

Jason Fossen also shared his thoughts on architecting AD in environments where some Windows servers reside close to the network's perimeter, such as in the DMZ or a screened subnet. He recommending implementing a  separate forest for DMZ servers that need to be domain members (perhaps with a one-way cross-forest trust to the internal forest), rather than joining DMZ servers to the internal forest directly. Jason continued:

The DMZ controller(s) will be located in a new perimeter network attached to a firewalling device.  When implementing a cross-forest trust, after configuring groups and permissions on the DMZ servers (which requires LDAP traffic), the only traffic that must be allowed through the firewall is Kerberos.  If the DMZ servers must be joined to the internal forest, then it’s better to place Read-Only Domain Controllers (RODC) in another perimeter network of the firewall for the sake of the DMZ servers.

Also, with the use of PKI, RADIUS, reverse proxy servers, etc., it has become less necessary to either join DMZ servers to the internal forest or to establish a one-way cross-forest trust from the DMZ forest to the internal one, even when users must authenticate with the internal forest credentials.

Jason's SANS course explores this topic in detail.

This note outlined the key points for AD traffic considerations. For additional guidelines, read through the articles referenced in the text above.

Liked this? Post it to Twitter!

-- Lenny

Lenny Zeltser - Security Consulting
Lenny teaches malware analysis at SANS. You're welcome to follow him on Twitter. You can also track new Internet Storm Center diaries by following ISC on Twitter.

Keywords:
1 comment(s)

New VMware Desktop Products Released (Workstation, Fusion, ACE)

Published: 2009-10-27
Last Updated: 2009-10-27 16:01:10 UTC
by Rob VandenBrink (Version: 1)
0 comment(s)

VMware Fusion 3.0 went from Release Candidate to General Availability last night, as did  VMware Workstation 7.0 and VMware ACE 2.6

Lots of new stuff - the feature I welcome the most is nested VMs.  This allows you to run ESX with guests inside of workstation (if you have enough memory that is).  This is a great feature if you are doing ESX work on your laptop.  This is common in both lab and testing, but we also use this a lot in training.    This feature has been in the workstation and fusion products (unsupported) for quite some time, but VMware is finally rolling it into the fold of supported features.

AES encryption of disk images is a feature that's been on ACE, but is now available on the other desktop products.  This is a great help to anyone doing PCI or HIPAA work in a VM.  You can now for instance transport a VM and use encryption native to the product, as opposed to adding a step and another product to get the encryption job done.  The encryption on disk also (maybe) fills the "data encryption at rest" requirement in many compliance frameworks.   Keep in mind though that achieving actual compliance with any compliance framework depends on a lot more than just encryption - it's best to involve your auditor before running sensitive VM's on a laptop.  This one new feature is very welcome and is certainly required in many compliance situations, but might not get you all the way to compliant just on it's own.


Other new features:
- support for Windows7 (and it's associated new graphics APIs) and Windows Server 2008.
- support for VMs with up to 4 processors and 32GB of memory (with a new 16GB laptop coming, I'm looking forward to this !)
- ALSA sound support for Linux ( this has been a long time coming ! )
- a nifty new "pause" feature, allowing you to pause a VM if you need some temporary processor power for your host or another VM
- a new Virtual Network Editor, which is long overdue (especially on Fusion !)

Interestingly, ACE now has the capability to create VMs, and Workstation now has P2V features.  It's really seeming like VMware is pushing all the products up one notch in the totem pole with this release - ACE seems to be turning into workstation, and workstation seems to be morphing into the old server product

Lots of posts on the release candidate features, it looks like the GA code has the same feature list (as you'd expect):

http://www.vmware.com/company/news/releases/fusion3-preorder.html
http://blogs.vmware.com/workstation/2009/10/workstation-7-release-candidate-available.html

/rob

Rob VandenBrink is a Security and Network Consultant at Metafore (www.metafore.ca)

0 comment(s)

Social Engineering in Real-World Computer Attacks

Published: 2009-10-27
Last Updated: 2009-10-27 12:41:40 UTC
by Lenny Zeltser (Version: 2)
4 comment(s)

Why bother breaking down the door if you can simply ask to be let in? Social engineering works, both during penetration testing and as part of real-world attacks. This note explores how attackers are using social engineering to compromise computer defenses.

Starting in the Physical World

We have spent most of our lives in the physical world, whose norms we know well. As a result, we tend to trust messages that come to us in the physical world more than those in the "virtual" world of the Internet:

 Other social engineering attacks in the physical world have been effective as part of penetration testing or research:

Malware Installation Tricks

Attackers increasingly rely on social engineering tactics to trick victims into installing malicious software. There are numerous variations of the approaches seen in the wild, including the following:

  • After initially infecting a PC with a fake anti-virus tool, attackers may redirect the victim's searches for technology review sites. The idea is that if the victim wants to determine the legitimacy of the downloaded anti-virus tool like AntiVirus2010, he'll be presented a fabricated review that extols the virtues of the fake product.
  • Attackers use search engine optimization (SEO) techniques to direct victims to malicious clones of legitimate sites. One such SEO technique involved entirely mirroring the legitimate sites and DDoS'ing the legitimate sites.
  • Malware authors may upload malicious versions of popular software to shareware sites and use botnets to download their files to inflate the download counter, as was performed by the Nugache worm. This tricks the victims into downloading malicious files, because the shareware site shows them as being most popular.
  • Social networking sites have been a hotbed for distribution of malware, often by sharing links via compromised accounts. For instance, this technique was employed by the Koobface worm to spread via Facebook, MySpace, and other such sites.
  • Spammers often send email messages that look like software upgrade advisories to trick victims into installing malicious programs. One of the recent examples involved a warning to download an upgrade to the Outlook Web Access client. Similar techniques involve the use of fake and real news bulletins, as was the case with malware-infused Michael Jackson spam.

Targeted Attack Tricks

Attackers may profile victims to include the person or company-specific social engineering elements in the intrusion campaign:

How else are Internet attackers using social engineering? If you have real-world stories to share, please send us a note.

Liked this? Post it to Twitter!

-- Lenny

Lenny Zeltser - Security Consulting
Lenny teaches malware analysis at SANS. You're welcome to follow him on Twitter. You can also track new Internet Storm Center diaries by following ISC on Twitter.

Keywords:
4 comment(s)

Comments


Diary Archives