Diaries

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

VMware Security Advisory: VMSA-2009-0015

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:

-- 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.

0 Comments

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

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 Comments

Cyber Security Awareness Month - Day 27 - Active Directory Ports

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.

1 Comments

http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpuoct2009.html

Social Engineering in Real-World Computer Attacks

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:

One example of this was the case of malware that began spreading via parking violation notices, which were placed on windshields of parked cars. The notices attempted to lure victims into visiting a malicious website.
Other physical world attacks involve phones, whereby attackers use compromised VoIP accounts to leave voice messages that invite victims to call the "bank" to handle a supposed problem with their banking account. Sometimes such "vishing" correspondence arrives via text/SMS messages.
In another physical world example, the Conficker worm manipulated the autorun.inf file on the infected USB key to trick the next victim into launching its malicious software.

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

Pen testers left USB keys in public areas, waiting for the employees to pick them up and insert them into their PCs at the office.
Pen testers sent CDs to the targeted organization, waiting for employees to insert them into their PCs at the office.
Researchers asked people to reveal their passwords in exchange for a pen and chocolates. (I hope many of these passwords were fake.)

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:

The attacker's email, instant, or social networking messages may be automatically customized based on the user's locale to make them seem more relevant, as was the case with the Waledac worm.
The attacker's messages may be spoofed to come from a trusted or expected sender, or may include content the victim expects to receive.
Attackers may use social networking and resume sites to profile the victim, so their communications are more likely to be read and acted upon.

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.

4 Comments

Published: 2009-10-26

Cyber Security Awareness Month - Day 26 port1433/1434 MSSQL

Port 1433 together with port 1434 are the ports most associated with MSSQL or to security people as the Slammer ports.

Port 1433 is typically used for database connections, but like all TCP/IP services it does not have to be and people do move the server to a different port. When alternate ports are used, then the SQL Server Browser, listening on port 1434, lets users connect to the database and identify which port is being used by the database. The port is also called the MSQL monitoring port by some people.

MSSQL has a number of security risks associated with it, most notably is the Slammer worm which appeared in January of 2003. More than six years later it is still going around the internet and is still one of the highest hit ports in our database. Mainly because it still works.

Now most people do not intentionally open up database ports to the internet, but a few of the Microsoft products included the desktop edition of MSSQL (MSDE) so many people inadvertently had these ports open and were infected.

A number of worms/bots have also exploited MSSQL through the default SA password which for a long time was blank. This was later fixed with a patch and has subsequently been addressed in the later versions of MSSQL. However we still see a lot of scans for the port and in penetration tests entry is often gained through misconfigured MSSQL servers.

In short, databases are accessed by applications there is no good reason for them to be directly accessible from the internet.

Mark H

1 Comments

Published: 2009-10-26

Today: ISC Login bugfix day. If you have issues logging in using OpenID, please email a copy of your OpenID URL to jullrich\at\sans.edu

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

0 Comments

Published: 2009-10-26

Web honeypot Update

We just released a significant update to our web honeypot. If you are running it, please update (and make sure automatic updates are enabled).

If you are not running the honeypot yet, here is how to get started:

Prerequisits:

- you will need Apache and PHP (should work on Windows, but we do most of our testing on Linux)
- you DOÂ NOT need to dedicate an IPÂ address to the honeypot. It will work fine as a virtual host.

Getting Started

- log in to "My ISC"/"My DShield" https://isc.sans.org/myisc.html
- click on "My Information" https://isc.sans.org/myinfo.html
- find the web logs signup form on the page (see image below). Fill in your information.

honeypot signup image

- The "Latest honeypot version" link will link to the honeypot. Download it
- create an empty directory (e.g. /srv/www/vhosts/webhoneypot )
- uncompress the webhoneypot into this EMPTYÂ directory. (tar xzvf webhoneypot.tgz)
- configure the honeypot using our configure script: lib/config.php

The 'docs' directory includes a sample apache configuration (honeypot.dshield.org.conf). You will need to adjust the directory.

Please let me know if you are running into any issues, and THANKS a lot for your help. The data will be publicly available to anybody interested in helping us analyze the data.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

0 Comments

Published: 2009-10-25

Cyber Security Awareness Month - Day 25 - Port 80 and 443

Port 80 and 443 are ports generally associated with "the Internet". Port 443/HTTPS is the HTTP protocol over TLS/SSL. Port 80/HTTP is the World Wide Web. Let's face it, port 80/443 are generally a given for being open on any type of filtering device allowing traffic outbound on your network. If web servers are being hosted, connections will be allowed inbound to those web servers. They are also two ports that pose a significant threat(s) to your network.

One reason for such a threat, is the very fact that we just mentioned: everyone generally associates it with the Internet and web traffic and its usually open. Sadly, it doesn't get watched that closely. I have heard the statement many times "its just people surfing the web and we ignore it cause there is too much traffic." The sad reality is that more often than not, the threat will come from people on your network surfing the web. The rise in browser based attacks is staggering to say the least.

For those that do want to watch it close, that poses a challenge as well. How do you filter? What do you filter? How do you do analysis on the traffic? Let me pose a example to you. I looked at a piece of malware about three years ago that used base64 encoded html comments, on a very benign web page, to pass commands. How do you detect that? Some software automatically defaults to port 80 if the primary port is available.

The above two threats applies to port 80 and 443 traffic. Now, let's just focus on 443 for a minute. It's encrypted traffic which means you can't read it. So what do you do? Unless you have a proxy on your network where you can inspect the traffic at that point or run a host based IDS etc., your other network tools are blind to what is there.

I have become a big fan and proponent of visual analysis for network traffic. With the amount of traffic we have on our networks today, visual analysis is in my opinion, one of the few viable options for trying to discern trends in traffic. Port 80 and 443 are prime candidates for that analysis. Things such as establishing what is normal for traffic loads, time of day, websites visited etc. can all be great baselines to know when something different starts to happen.

If you have any comments or suggestions for port 80 and 443, then please let us know. Also, there are other services that you know of that run on port 80, please post those as well!

1 Comments

Published: 2009-10-24

Cyber Security Awareness Month - Day 24 - The Small Services

The ports below 20 and also 37 are frequently called the "small services" and can be safely blocked. For a quick review, here is what is going on down at the bottom of the port list:

tcpmux    1/tcp    #TCP Port Service Multiplexer [rfc-1078]
tcpmux   1/udp    #TCP Port Service Multiplexer
compressnet    2/tcp    #Management Utility
compressnet    2/udp    #Management Utility
compressnet    3/tcp    #Compression Process
compressnet    3/udp    #Compression Process
rje     5/tcp    #Remote Job Entry
rje            5/udp    #Remote Job Entry
echo    7/tcp    #
echo    7/udp    #
discard 9/tcp    #Discard
discard 9/udp    #Discard
systat      11/tcp    #Active Users
systat      11/udp    #Active Users
daytime    13/tcp    #
daytime 13/udp    #
netstat    15/tcp    #
qotd      17/tcp    #Quote of the Day
qotd 17/udp    #Quote of the Day
msp   18/tcp    #Message Send Protocol
msp    18/udp    #Message Send Protocol
chargen    19/tcp    #Character Generator
chargen    19/udp    #Character Generator
ftp-data      20/tcp    #File Transfer [Default Data]
ftp-data      20/udp    #File Transfer [Default Data]
time 37/tcp    #Time
time      37/udp    #Time

An interesting attack was developed many years ago using the echo and chargen ports. echo will send back whatever characters are sent to it, while chargen will generate random characters. By spoofing source and destination addresses/ports, it was easy to inject fake packets into a network that would generate characters from Alice's chargen port and send them to Bob's echo port, which would then echo them back to Alice's chargen which would generate more characters to send to Bob, and....I think you get the picture. Instant denial of service attack.

Cisco's routers can enable/disable the "small servers" on those devices (echo, discard, and chargen) by using these commands:

Router(config)# service udp-small-servers
Router(config)# no service udp-small-servers

Router(config)# service tcp-small-servers
Router(config)# no service tcp-small-servers

In Unix systems, edit the inetd.conf (or equivalent) file to comment out these services if you don't use them. Odds are pretty good that you don't.

If you have any additional thoughts or comments on the Small Services please let us know via our contact form, or simply add your public comments via the comment link below.

Marcus H. Sachs
Director, SANS Internet Storm Center

1 Comments

Published: 2009-10-24

What's with tcp/0?

In case you did not notice, the DShield system is going nuts with reports on tcp/0. Stephen Hall wrote a nice Cyber Security Awareness Month diary on the subject of tcp/0 earlier this month. Did the bad guys read it and start launching probes? Is it Akamai or some other caching service? If you can do some full packet captures of any tcp/0 traffic hitting your firewalls let us know what you find out. Send us your analysis via our contact page.

Marcus H. Sachs
Director, SANS Internet Storm Center

0 Comments

Published: 2009-10-24

Windows 7 - How is it doing?

Microsoft's Windows 7 operating system was officially released on Thursday October 22nd. I'm sure that many of our readers were lined up outside their local candy stores to buy an early copy. For those who have successfully installed it, tell us about your experience. Was it good, bad, or ugly? Any pearls of wisdom you'd like to pass along to others? You can comment directly by using the comment link below or you can send us a private message by using our contact form. Either way, we'd like to hear about some early experiences. We'll update this diary from time to time with reader comments.

Marcus H. Sachs
Director, SANS Internet Storm Center

5 Comments

Published: 2009-10-23

Cyber Security Awareness Month - Day 23 port 179 TCP - Border Gateway Protocol

What is BGP? It is the default Exterior Gateway Protocol for the INTERNET.
It is also often the Interior Gateway Protocol for ISPs.
It is used to exchange routing information with other ISPs and BGP speaking customer routers.

There are two major concerns about the security of BGP.
One is router table corruption either deliberate or accidental.
At DEFCON last year there was a "kewl" bgp hijack method demo'ed.
The concepts weren't really new and methods to mitigate this were well known just not implemented in many cases.
http://isc.sans.org/diary.html?storyid=4975

Another concern is blindly resetting BGP sessions causing the routers involved to lose route information. This diary has a fairly complete set of references for the "blind TCP RST of persistent TCP connections within the window size" vulnerability first released in 2004
http://isc.sans.org/diary.html?storyid=171
This vulnerability was exasperated somewhat by route servers and looking glass implementations that provided the five tuple needed thus in some cases you only had to "guess" the correct sequence number within the windows size.
http://www.merit.edu/mail.archives/nanog/2004-04/msg00684.html

The "Blind connection reset attacks against TCP" published by F Gont here:
http://tools.ietf.org/html/draft-gont-tcpm-icmp-attacks-00
are harder to mitigate against since icmp packets wouldn't be expected to have MD5 authentication.

There are several recommended mitigations for BGP attacks.
GTSM:
http://www.ietf.org/rfc/rfc3682.txt

Pros: Its simple to implement given that most BGP peers are one or 2 hops away from each other.
So a valid peer should be able to get a BGP packet to their peer with a TTL of 255 or 254 in most cases.
It's easy for the router to check as it is a simple Inbound_TTL >= TTL_Allowed type comparison.
It is nearly impossible to spoof an attack on a BGP session that is protected by GTSM as you have to be either directly connected or at least as close hop count wise as the expected peer.

Cons:
Not all BGP speakers support GSTM.
Not all BGP speakers have an initial TTL of 255.
Not all BGP speakers use an initial TTL of 255 for resets when they have lost Session State of a BGP session. So the TCP reset may come from the OS stack which may not be GSTM aware.
There are some tunneling methods that MAY allow packets into an ISP with an unmodified TTL but those are corner cases that can be dealt with depending on implementation.

MD5 authentication of BGP sessions:
http://tools.ietf.org/html/rfc2385
Pros:
Most BGP implementations support this.
Without the "shared secret" used between peers it is nearly impossible to successfully launch a spoofing attack.
Cons:
Because of the way the rfc was written it allowed the vendors to ignore MD5 authentication for connectionless resets. This can impact BGP if one of the peers lose state or has a stale connection (see section 4.1 of the rfc above).
MD5 authentication itself can be attacked, as it can be a compute intensive operation depending on the vendor's implementation.
It doesn't protect against NON-TCP based attacks.

Additional security measures recommended for BGP speakers.
Implementing prefix filtering to block advertisements of rfc1918 space and bogons.
http://www.team-cymru.org/Services/Bogons/

Implementing prefix filtering to block customers from advertising cidr blocks they weren't issued.
Implementing prefix filtering based on cidr block advertisement size.
ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter-Templates/Prefix-List-Filtering-Mar-03.pdf

A good set of templates to secure BGP is available for several routers here.
http://www.team-cymru.org/ReadingRoom/Templates/

0 Comments

Published: 2009-10-22

Cyber Security Awareness Month - Day 22 port 502 TCP - Modbus

"Modbus Protocol is a messaging structure developed by Modicon in 1979. It is used to establish master-slave/client-server communication between intelligent devices. It is a de facto standard, truly open and the most widely used network protocol in the industrial manufacturing environment. It has been implemented by hundreds of vendors on thousands of different devices to transfer discrete/analog I/O and register data between control devices. It's a lingua franca or common denominator between different manufacturers. One report called it the "de facto standard in multi-vendor integration". Industry analysts have reported over 7 million Modbus nodes in North America and Europe alone." From: http://www.modbus.org/faq.php

Modbus was oroginally developed as a proprietary communication/command protocol for SCADA/Process Control systems. It has been migrated to TCP/IP since 1999. There really isn't much to the protocol specification at all.

One of the first main issues with Modbus is that it is not designed to be run on open networks, it was intended to be used on dedicated lines, such as a serial connection, or a closed network. Ideally this is achieved through an airgap between the PCS network and the corporate IT network. It is however quite convenient to be able to monitor or even control these systems from a corporate desktop. The devices that communicate using Modbus are also typically not designed to be on open networks, and often fail from a port or vulnerability assessment scan. There really isn't much to 'hacking' these devices, if you can talk to them they do whatever you tell them to.

The Modbus protocol itself contains no security whatsoever. If you can communicate directly with a Modbus server or client you can issue commands. This can be quite important depending on the function that the slave devices are performing. The only real choices are as mentioned previously to completely airgap Modbus from any other network, or severely limit access to authorized masters.

This brief article is just the tip of the iceberg for the Modbus protocol, and any discussion of Process Control, SCADA systems and security.

Additional reading:

http://www.digitalbond.com/wiki/index.php/Modbus

http://www.mudynamics.com/resources/collaterals/MODBUS-v3.pdf

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

0 Comments

Published: 2009-10-22

Truecrypt 6.3 released

from their version history notes:

Full support for Windows 7.
Full support for Mac OS X 10.6 Snow Leopard.
The ability to configure selected volumes as 'system favorite volumes'.

TrueCrypt is a software system for establishing and maintaining an on-the-fly-encrypted volume (data storage device).

More information here: http://www.truecrypt.org/docs/?s=version-history

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

0 Comments

Published: 2009-10-21

Cyber Security Awareness Month - Day 21 - Port 135

Welcome to day 21. Today we will talk about port 135.

In a simple way, we have these basic information:

Port: 135
Service Name: epmap/loc-srv
Popular Name: Microsoft DCE locator
Udp or Tcp: Both

Description:
Port 135 hosts an important service on Windows hosts. When a host wants to connect to a RPC service on a remote machine,
it firsts checks with the destination machine on port 135, to know which port is being used by the service it wants to connect into. (Yes, quite close to *nix Portmap)
The Microsoft DCE locator, which runs on port 135 will then return the port on which the desired service is running.
The original requester host will then connect to this port.

May be used by:
* DHCP server
* DNS server
* WINS server

What makes this a port of interest is that in the past, it used have lots of vulnerabilities, which were exploited by malicious users and for worms,
as the old Blaster or for bots that had the exploit on its database, like the old phatbot/sdbot.

A good move form Microsoft was to include on Windows XP ServicePack 2 a firewall default rule to block external access to this port.

However, there are still some situations where you may need to add some exceptions to remote connection on this port, such as:

- some MS SQL Server scenarios.

- some WMI (Windows Management Instrumentation), which is quite useful for CLI administration.

Whatever is the reason you need it to be open, make sure you will restrict it at the maximum possible way.

Example of a port 135 traffic (from pcapr):

01:48:35.511258 IP 1.0.0.1.3949 > 1.0.0.2.135: S 2182823608:2182823608(0) win 8760 <mss 1460,nop,nop,sackOK>
01:48:35.536500 IP 1.0.0.2.135 > 1.0.0.1.3949: S 3596070259:3596070259(0) ack 2182823609 win 17424 <mss 1452,nop,nop,sackOK>
01:48:35.974438 IP 1.0.0.1.3949 > 1.0.0.2.135: . ack 1 win 10164
01:48:35.999130 IP 1.0.0.1.3949 > 1.0.0.2.135: P 1:73(72) ack 1 win 10164
01:48:36.035866 IP 1.0.0.2.135 > 1.0.0.1.3949: P 1:61(60) ack 73 win 17352
01:48:36.561338 IP 1.0.0.1.3949 > 1.0.0.2.135: . 73:1525(1452) ack 61 win 10104
01:48:36.575457 IP 1.0.0.1.3949 > 1.0.0.2.135: P 1525:1681(156) ack 61 win 10104
01:48:36.580581 IP 1.0.0.1.3949 > 1.0.0.2.135: F 1681:1681(0) ack 61 win 10104
01:48:36.601318 IP 1.0.0.2.135 > 1.0.0.1.3949: . ack 1681 win 17424
01:48:36.605455 IP 1.0.0.2.135 > 1.0.0.1.3949: P 61:101(40) ack 1681 win 17424
01:48:36.614687 IP 1.0.0.2.135 > 1.0.0.1.3949: F 101:101(0) ack 1682 win 17424
01:48:39.871749 IP 1.0.0.2.135 > 1.0.0.1.3949: FP 61:101(40) ack 1682 win 17424
01:48:46.433952 IP 1.0.0.2.135 > 1.0.0.1.3949: FP 61:101(40) ack 1682 win 17424
01:48:59.558881 IP 1.0.0.2.135 > 1.0.0.1.3949: FP 61:101(40) ack 1682 win 17424

------------------------------------------------------------

Pedro Bueno (pbueno /%%/ isc. sans. org)

Twitter: http://twitter.com/besecure

1 Comments

Published: 2009-10-21

Rapid7 purchases Metasploit

Woke up this morning to find the news in my inbox, that Vulnerability Management company Rapid7 purchased Metasploit. Personally, I think this is a good thing. Anytime there can be commercial funding and backing put behind an Open Source program in order to further it's development, I consider it a good thing. I know this model works, as I work for Sourcefire. We have a few open source programs ourselves.

Better funding = better (more) exploits = better pen-test tool. Not that Metasploit isn't already awesome, because it is, but this will make Metasploit turn another corner in its (already successful) evolution.

I applaud HD's (and of course everyone else on the Metasploit team's) work, and may this acquisition further the success of the platform.

WordPress Hardening

Today one of our readers sent an interesting post from the developers of WordPress. It is about a just released version 2.8.5.

This version is called as the "Hardening Release", which I thought was quite great! According the post, these were new security features from the new 2.9 series that they decided to backport to the 2.8.x tree.

Among the new features/fix you can see:

"A fix for the Trackback Denial-of-Service attack that is currently being seen.
Removal of areas within the code where php code in variables was evaluated.
Switched the file upload functionality to be whitelisted for all users including Admins.
Retiring of the two importers of Tag data from old plugins."

Why does this news deserve a diary? For two reasons:

1) Wordpress is one of the most popular "publishing plataform" (blogs,etc...) and free...

2) In 2008 there were 23 vulnerabilities for it and in 2009 there are 12 vulnerabilities found so far...

So, this effort from the developers really deserves our attention and kudos...

---------------------------------------------------------------------------------------------------------------------------

Pedro Bueno (pbueno /%%/ isc. sans. org)

Twitter: http://twitter.com/besecure

0 Comments

Published: 2009-10-20

WASC 2008 Statistics

The Web Application Security Consortium (WASC) released last Friday the 2008 statistics, compiling website vulnerability data from more than 12K sites and detecting near 100K vulnerabilities. As in previous years, Cross-Site Scripting (XSS), information leakage, and SQL injection are at the top of the list, but with a few significant variations:

Compared to 2007, the number of sites with wide spread SQL Injection and Cross-site Scripting vulnerabilities fell by 13% and 20%, respectively, however, the number of sites with different types of Information Leakage rose by 24%. On the other hand, the probability to compromise a host automatically rose from 7 to 13 %.

The statistics are mainly collected through (black & white box) automated testing. Therefore, once again and IMHO, one of the most frequent vulnerabilities, Cross-Site Request Forgery (CSRF or XSRF), is not properly reflected in the report. All the details are available on the WASC Statistics Project website (WASS) both in HTML and PDF format.

Definitely, if you plan to take actions to improve the security of your web-apps (and you should!), start focusing on these four vulnerabilities: XSS, information leakage, SQLi and CSRF!

--
Raul Siles
www.raulsiles.com

0 Comments

Published: 2009-10-20

Oracle Critical Patch Update (CPU) - October 2009

Today, October 20, Oracle releases its quarterly CPU. There are lots of vulnerabilities DBAs must act upon ASAP. I specially want to point out that, although it "only" addresses 38 vulnerabilities...

16 fixes address flaws in the Oracle database (six can be exploited remotely without user interaction)
3 fixes address flaws in the Oracle Application Server (two can be exploited remotely without user interaction)
8 fixes address flaws in the Oracle Applications Suite (five can be exploited remotely without user interaction)

More (advance) information in the pre-release announcement, and in a few hours...:

--
Raul Siles
www.raulsiles.com

0 Comments

Published: 2009-10-20

Cyber Security Awareness Month - Day 20 - Ports 5060 & 5061 - SIP (VoIP)

Ports 5060 and 5061, both on TCP and UDP, are associated to the Session Initiation Protocol (SIP) by IANA. In particular, port 5060 is assigned to clear text SIP, and port 5061 is assigned to encrypted SIP, also known as SIP-TLS (SIP over a TLS, Transport Layer Security, encrypted channel). Unfortunately, the standard TLS (successor of SSL) can only be established over TCP. Does this mean SIP UDP-based communications have to travel unencrypted? Fortunately not. An IETF draft covering SIP-DTLS is on the queue (DTLS is Datagram TLS, that is, UDP)... but... what is SIP?

The Session Initiation Protocol (SIP) is a signaling protocol for Internet multimedia conferencing and communications, such as Voice over IP (VoIP). It is extensively used on VoIP architectures, and is becoming the IETF alternative and "natural" replacement to the complex H.323 signaling protocol. As a signaling protocol, SIP is mainly focused on managing and negotiating all the features of VoIP sessions (or other multimedia-based protocols), such as setting up and tearing down VoIP calls.

SIP is probably one of the most complex protocols based on the length of its RFC, RFC 3261, and its flexibility and extensibility, what has caused the publication of multiple standards that update and add new functionality to it. Today, a search by SIP on RFC Editor returns 157 references.

However, it is a text-based request and response protocol, very similar to HTTP (web): SIP messages are made of headers and body, it allows multiple request methods (REGISTER, INVITE, ACK, BYE, etc), it defines entities as URI's (Uniform Resource Indicators), and the set of responses is categorized in different groups (success (2xx), redirection (3xx), etc); all them common features available in HTTP. SIP messages are ASCII encoded and can make use of the standard Multipurpose Internet Mail Extensions (MIME) capabilities. This protocol is tightly integrated with the most commonly used media protocol, RTP (Real-time Transport Protocol), used to carry the streaming and real-time multimedia sessions. The ports used for RTP communications are dynamically negotiated by SIP when a new VoIP or multimedia session is established. This behavior is very similar to FTP, where the control channel manage the communication (TCP/21), and negotiates the ports for the data channel, the one that transports the information (TCP/20 or dynamically negotiated). For those readers interested on inspecting a SIP packet capture, check this sample from the Wireshark repository, where SIP Digest authentication is used.

Why SIP is (or can be) an important protocol? As VoIP and other multimedia capabilities, such as video on demand (VoD) and triple play communications, are being widely deployed by service providers and companies, SIP is silently entering in our networks. However, some providers do not use SIP over the standard ports, and select their own set of ports; this obviously breaks communication capabilites between providers as it is like setting up your web server on a port different than TCP/80 (you need to know in what port it is listening on). Additionally, if SIP P2P (peer to peer) communications get adoption, where intermediate proxies and servers are not required for two (or more) users to establish direct multimedia communications, we might end up opening these ports (TCP & UDP / 5060 & 5061) in most firewalls, and specially, on SOHO environments.

You can start today looking for SIP traffic on your networks. Capture some traffic and analyze it. Using Wireshark you can apply different display filters to confirm if SIP is there:

udp.port == 5060 or udp.port == 5061

tcp.port == 5060 or tcp.port == 5061

sip or sdp

frame contains "SIP"

ssl or dtls

Let's get ready for the upcoming SIP and VoIP wave!

--
Raul Siles
www.raulsiles.com

SANS VoIP Security (SEC540)

0 Comments

Published: 2009-10-19

Scam Email

New week, new scams. Two emails showed up on our ISC scam radar this morning.

One seems directed at universities, and is informing students that their email quota is exhausted and asks them to connect to a web site (studentresume. c.la) to re-enable their account. The site includes an iframe from planetchiltern. com and doesn't even TRY to look like the web site of an university. It still asks for your userid and password, though...

Another one pretends to come from Microsoft and warns users on a rapidly spreading Conficker.B infection (sic!). Conveniently enough, the email includes the "patch and removal tool".

If you fell for either of these, now would be a good time to confess to your sysadmin :).

[Thanks to ISC readers Matt and Joe for the samples]

1 Comments

Published: 2009-10-19

Backed up, lately ?

At first, when a pal of mine called to rant about the new tendency of his OS to go "hasta la Vista", I laughed. He is an IT professional, and a little swine flu in his computer is no big deal. Or so I thought. What started as an occasional hiccup on Thursday apparently turned into an unspectacular but complete Exitus on Friday: The computer simply didn't boot no more.

Of course we all know, often from individual experience, that a disk drive with a "mean time between failure" (MTBF) of indicated 500'000 hours is NEVER the one drive that we bought. Rather, we usually seem to get the "mean failure" version, whereas other people must be getting the "time between".

Nevertheless, this apparently hasn't taught us to be diligent with our backups. As far as backups of data on personal PCs go, most people are either in the "ignorant and negligent" or "knowing and diligent" camps. The special corner of data loss hell, the "knowing but negligent" section, seems to be solely populated by IT and technology people.

It doesn't have to be you. Go buy that USB or eSATA drive, and get that copy made TODAY.

11 Comments

Published: 2009-10-19

Cyber Security Awareness Month - Day 19 - ICMP

ICMP, the Internet Control Message Protocol, was originally designed (RFC 792, 1981) to convey error conditions back to the sender of an IP packet. In today's Internet, ICMP is somewhat of an anachronism, since pretty much all programs and protocols contain their own error detection and recovery logic.

ICMP packets don't use port numbers like UDP and TCP do, but have a message type and message code field in the header instead.

ICMP/8 and ICMP/0
The ICMP packets that you probably are most familiar with are "ICMP Type 8 code 0" and "ICMP Type 0 Code 0", commonly known as "ping" and "ping reply". A "ping" is still the most commonly used command by system administrators to determine if a box is "up" and to check "round trip times" between two systems. While there are more reliable methods to accomplish either of these tasks, good old "ping" still prevails.

Ping packets can also have a data portion (payload). This triggered a big hunt for "covert channels" more than a decade ago, when an article on "Project LOKI: Arbitrary information tunneling" appeared in Phrack Magazine. Today, most firms and institutions keep "ping" blocked across their perimeter firewall, but primarily since the impact of blocking it is marginal, and not because of "covert channel" concerns. It has been a long time since mal-code authors last effectively used ping for communication. And why should they - http and https are working just fine across most corporate firewalls.

Another attack, the "smurf", relied on ICMP's ability to respond to a broadcast packet. Basically, a single "ping" sent to the broadcast address of a subnet was answered by all the active hosts on that subnet. Very neat to quickly map what's out there, but also a really good "amplifier" in a denial of service attack. This non-feature of ICMP has therefore long since been fixed: All current Operating Systems have broadcast ICMP either off by default, or support a configuration parameter to turn it off.

ICMP/3
ICMP Type 3, "Destination Unreachable", is next to "ping" the most common of the ICMPs on today's Internet, primarily thanks to the increasing use of UDP in peer to peer networks. Unlike TCP, where the recipient of a packet can respond with a "Reset" (RST) if communication is undesired or not permitted, UDP contains no such mechanism and relies on ICMP to convey its displeasure. ICMP Type 3 Code 3, "port unreachable" is the usual answer returned on an UDP packet sent to a port that is not active (listening).

One of the cool features of ICMP Type 3 is that the error messages actually contain the first few bytes of the original packet that triggered the error. Firewalls unfortunately tend to ignore this information, and only display a useless information like "Denied ICMP type=3, code=3 from 88.1.2.3 on interface outside". A good old tcpdump or decent IDS will tell you more:

18:12:34.068212 IP 88.1.2.3 > 173.2.3.4: ICMP 88.1.2.3 udp port 53 unreachable, length 65
0x0000: 45c0 0055 95f5 0000 4001 4d0c 5801 0203 E..U....@.M.X.,.
0x0010: ad02 0304 0303 941a 0000 0000 4500 0039 ..dx........E..9
0x0020: 6749 0000 7211 4a84 ad02 0304 5801 0203 gI..r.J...dxX.,.
0x0030: c0df 0035 0025 3608 000a 0100 0001 0000 ...5.%6.........
0x0040: 0000 0000 0377 7777 0369 626d 0363 6f6d .....www.ibm.com
0x0050: 0000 1c00 01

At offset 0x001C (marked in blue), you can see the start of the original datagram. In this case, the system at 88.1.2.3 responded with an ICMP/3:3 "Port unreachable" because 173.2.3.4 apparently sent a DNS request for "www.ibm.com" to 88.1.2.3, and the latter does not seem to be running a DNS service. If you ever find your firewall under a deluge of ICMP/3 packets, sniffing them to determine the embedded original packets could help to tell you more.

ICMP/3 Type 4, "Fragmentation Needed but Don't Fragment Bit Set" is used to determine the maximum size per IP packet that a path between source and destination can support. This so-called "PMTU Discovery" helps to ensure that packets are sent at the maximum size that can squeeze through, which avoids fragmentation and reduces the bandwidth used for packet headers as compared to actual payload. In the frenzy to ban all ICMP through firewalls a decade ago, the rather useful ICMP 3/4 messages got blocked along with everything else. PMTU discovery is largely defunct today.

ICMP/11
An ICMP/11 packet is triggered when a packet dies off because its internal "time to live" (TTL) counter expired. IP packets start their journey with a TTL of usually 255, and this counter is decremented at every network hop the packet traverses. When the counter reaches zero, the packet is discarded, and an ICMP/11 error generated. ICMP/11 are also used by the "traceroute" program, which sends packets with deliberately low TTLs and keeps track of the origins of any ICMP/11 error message it receives. By slowly counting up from the low initial TTL, a hop-by-hop mapping of the network nodes between source and destination can be performed.

The IETF started work on a paper that lists both the "threat" of ICMP and "impact" caused when an ICMP message is blocked at the perimeter. Today, a lot of firms block everything ICMP, and accept that doing so can lead to delays and time-outs in some UDP based applications. A less paranoid and equally well accepted practice is to permit ICMP/11:0 and ICMP/3:4 error replies from the outside, but to rate-limit these packets to prevent flooding.

But this is the Cyber Security Awareness Month. So ... time to improve your awareness: If you currently have all ICMP blocked on your perimeter, sniff the ICMP traffic on the outside of the firewall for a day to see what you are missing. If you currently permit ICMP through your perimeter, sniff the ICMP traffic for a day to see what it is that you are letting through.

There's no telling what you might find, in either case :)

1 Comments

Published: 2009-10-18

Computer Security Awareness Month - Day 18 - Telnet an oldie but a goodie

I mentioned to my collegue that I would be writing a Handler diary today about telnet, his ears perked up and he said, "That's my favorite protocol, you know!". I'll bet there are a lot of you out there with the same enthusiasm about this age old favorite.

Telnet is a grandpa(ma) of protocols. It was the first application protocol on ARPAnet in 1969. The RFC number is two digits for goodness sake! RFC97, First Cut at a Proposed Telnet protocol, February 1971. Peeps, the song of the year was "Joy to the World" by Three Dog Night! Dev continued during the 70's and the final version was released in May of 1983. (Every Breath You Take, by The Police, if you were wondering).
It took a while to deal with the difficulty in communicating with different manufacturers. NVT (Network Virtal Terminal) standardized and fictionalized the terminal to enable a communication standard. Telnet is a symetric communication on port 23 between a Telnet Client and Telnet Server. Quality of service is reliable, rate controlled and fully-duplexed protocol. IDS Behavior consists of burst activity during the session initiation, and only occasionally thereafter.

One of the first "user friendly" telnet application programs was a weather warning site. Things we take for granted now. Log into the application and your choices were wind, temperature, etc. Telnet is also usable through SMTP and HTTP. You can mail, you can "GET"... what else could you want in a tool?

Telnet is priceless to engineers troubleshooting routers and switches. It is also a hackers first choice in the pen-test of your network. Easy catch!

The old cyber doomsday scenario serves to entertain but remind us, even as we laugh, that there is no such thing as a 100% secure computer. What are your telnet settings?

Tell us an oldy but goody about your experience with this wonderful protocol. We'll will post the most entertaining with the group as they come in.

Come on ......Jeramiah was a bullfrog!.... WoooooHooooo!

Mari Nichols

Handler on Duty

3 Comments

Published: 2009-10-17

Unusual traffic from Loopback to Unused ARIN address

Lode sent in some unusual traffic he is seeing from one of his servers. The traffic is Protocol 0 (IPv6 Hop by Hop), originates from a Loopback address and is destined to 108.22.0.0, which used to be IANA reserved but recently was allocated to ARIN, but is currently not in use.

13:02:52.012656 IP (tos 0x7,CE, ttl 255, id 29423, offset 0, flags [none], proto: Options (0), length: 20) 127.0.0.181 > 108.122.0.0: ip 0
13:02:52.012699 IP (tos 0x7,CE, ttl 255, id 29423, offset 0, flags [none], proto: Options (0), length: 20) 127.0.0.25 > 108.122.0.0: ip 0
13:02:52.012743 IP (tos 0x7,CE, ttl 255, id 29423, offset 0, flags [none], proto: Options (0), length: 20) 127.0.0.96 > 108.122.0.0: ip 0
13:02:52.012788 IP (tos 0x7,CE, ttl 255, id 29423, offset 0, flags [none], proto: Options (0), length: 20) 127.0.0.187 > 108.122.0.0: ip 0

Some searching shows references to this traffic from Solaris (this server is Debian Linux) systems dating back to at least 2002, but I couldn't find any concrete solutions. One reference suggests this traffic might be related to a misconfigured rootkit.

Anybody who knows anything about this traffic and can provide insight please contact me via our contact page.

-- Rick Wanner - rwanner at isc dot sans dot org

0 Comments

Published: 2009-10-17

Mozilla disables Microsoft plug-ins?

A couple of readers have indicated that this evening when they started Firefox it disabled the Microsoft plug-ins Windows Presentation Foundation and Microsoft .NET Framework Assistant 1.1. These plug-ins have been the source of some controversy since it was revealed earlier this week that Microsoft had patched them as part of patch Tuesday.

While the people over at Mozilla have recommended disabling these plug-ins, their is no indication over at the Mozilla Blogs of why this action was taken.

Anybody have any details of what is going on?

-- Rick Wanner - rwanner at isc dot sans dot org

2 Comments

Published: 2009-10-17

Cyber Security Awareness Month - Day 17 - Port 22/SSH

Welcome to CSAM Day 17! Today is brought to you by Secure Shell (SSH) commonly deployed on port 22/TCP.

SSH has become ubiquitous as a mechanism for command line access to *nix systems, and is sometimes deployed on Windows systems as well. As the Dshield graph for port 22 shows, it is a popular target for attackers. These attacks usually take the form of attempts to brute force root accounts and other accounts with weak passwords.

My primary method of protecting SSH servers is threefold:

Deploy the SSH server on a port other than 22/TCP. It appears that the SSH probes on the Internet at this time are focusing their interest on the standard SSH port. My personal server is deployed on a non-standard port and I have not had any attempts to login in over two years.
Deploy one of the SSH brute force prevention tools like DenyHosts, fail2ban, blockhosts, etc. On one of the servers I run where I have to deploy on the standard SSH port DenyHosts has blocked 65 IPs which have attempted brute force attacks in the last month.
Disallow remote root logins. Most SSH servers provide a mechanism to disallow the ability to login to a root account using SSH. In OpenSSH this is done by setting PermitRootLogin to "no" in the /etc/ssh/sshd_config file. This forces users to login using a user account and escalate privilege using su or sudo to become root.

What strategies do you use to secure SSH?

Do you have any strategies for protecting SSH servers deployed on Windows?

Please submit your suggestions through our contact form or via the diary comment system. I will summarize throughout the day.

UPDATES:

Faisal pointed out that I was remiss in not mentioning SSH keys. If you use keys for authentication and disable password authentication via SSH then SSH brute force attacks cannot succeed. In OpenSSH password authentication can be turned off by setting PasswordAuthentication to "no".

Joanne points out that there are alternatives to using brute force prevention tools. In her case she uses the iptables firewall to only permit one SSH connection, successful or not, every three minutes. Joanne also points out that if you must use passwords at least make sure the users use good ones.

Ned maintains a securing SSH page over at the CentOS wiki. It describes in detail how to implement some of the ideas presented here and more.

Sven sent a number of strategies. First he suggested using AllowGroups to limit access to a group of people. He also recommended that if users only require file transfer capability alternative shells like scponly can be utilized. He also points to ChrootDirectory which can be used as a chroot jail for SSH.

Gerard is a fan of sshdfilter. It is another of the anti-brute forcing tools, but it is an ssh wrapper and doesn't use tcpwrappers for blocking but rather creates iptables or ipfw rules to facilitate the blocking.

-- Rick Wanner - rwanner at isc dot sans dot org

0 Comments

Disable MS09-054 patch, or Firefox Plugin?

The .NET Framework 3.5 SP1 installs a “Windows Presentation Foundation” plug-in in Firefox. That in of itself may be cause for concern. But wait, there is more. MS09-054 was issued to address an IE vulnerability (CVE-2009-2529). As it turns out the vulnerability could also be exploited via Firefox. If you could launch XBAP using a browser the vulnerability could be exploited. For users of either browser it is recommended to disable XBAP. So essentially a security fix introduced additional issues? The irony is, well...

More information from Microsoft is available here.

So, if you use Windows, install patches, and also have Firefox, oddly enough you will want to read the following Microsoft KB article entitled "How to remove the .NET Framework Assistant for Firefox"

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

2 Comments

Multiple Vulnerabilities in Cisco Wireless LAN Controllers

The title pretty much says it all. Please check out the Cisco advisory here.

Cheers,
Adrien de Beaupré
EWA-Canada.com

2 Comments

Cyber Security Awareness Month - Day 16 - Port 1521 - Oracle TNS Listener

By default when you install Oracle the TNS Listener is on tcp port 1521. It handles network requests to be passed to a database instance. If it not appropriately secured commands can be sent to the listener, the listener can be shut down, or the databases can be queried. There have been a number of vulnerabilities over the years that have been actively exploited specific to the TNS Listener.

If you check the Dshield database for the last while port 1521 has appeared in the 'top 10' a number of times. It would appear as though if you install Oracle it is highly recommended not to expose it to the Internet (or any untrusted network). Obviously a number of people are actively looking for Oracle instances. http://www.dshield.org/port.html?port=1521

Some best practices for the TNS listener:

Restrict access to this port
Assign a password to the listener
Install patches

Some examples of CVE entries that involve the TNS Listener:
CVE-2008-2625, CVE-2007-5507, CVE-2007-2120, CVE-2006-0265, CVE-2005-3206, CVE-2005-3207, CVE-2004-1369, CVE-2003-1116, CVE-2002-1118, CVE-2002-0965, CVE-2002-0509, CVE-2002-0567, CVE-2001-0498, CVE-2001-0499, CVE-1999-0784, CVE-2000-0986

Some recommended reading: the Oracle Database Listener Security Guide http://www.scribd.com/doc/22455/Oracle-Database-Listener-Security-Guide

Please contact us if you have any comments or would like to add to this diary entry.

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

0 Comments

VMWare updates ESX

A duo announcements by VMWare highlight a new patch, and an updated one fixing their enterprise offering, ESX which addressed 51 CVE's worth of issues.

The majority of those however are within the Java Runtime (JRE) bundled with the product.

You can find more out on their list server where the following updates are released:

VMSA-2009-0014

VMSA-2009-002.1

Steve Hall | ISC Handler

0 Comments

Published: 2009-10-15

Cyber Security Awareness Month - Day 15 - Ports 995, 465, and 993 - Secure Email

Email has become a mainstay for both businesses and individuals. It seems a day does not go by that we are online checking for that ever important message from someone important to us. In the business world email is now our most important and timely form of communications. Information is passed from boss to employee – employee to boss –
owner/manager to employee groups and employee to employee. Email is a way we can make sure that our message is heard and acted upon. I for one could not function even a day without my email.

Email security is the process of using encryption to send messages that can only be opened and read by the intended recipient. Sending an email without encryption is much like sending a postcard through the Postal Service, it can be read by everyone who handles it on his way through the system from the sender to the receiver.

Most of the email sent today is sent using standard SMTP without using encryption or authentication. This email is sent on port 25 in clear text format and is exposed to view. This means that there is a danger that the email can be intercepted and read by anyone, anywhere. Now for most of the email that I send and receive this is not really a problem. I really don’t care if anyone has my super Chocolate Chip Cookie recipe or my Super Hot Chili recipe. I am however involved in some organizations that provide FOUO (For Official Use Only) information. For this information I need to protect the data from prying eyes. So how do I do that?

There are some really great client side utilities such as Secure MIME (S/MIME) or Pretty Good Privacy (PGP). These programs however require user involvement. The user has to know when and how to use the program and the recipient has to have the “Key” to unlock the encryption. This could be a problem for some of the users that can barely use their email.

A perhaps better place to focus your security efforts is securing your SMTP traffic. There are a lot of good articles about securing SMTP traffic and the basics are the same whether you are using Linux mail programs or Microsoft Exchange or Novell Groupwise. However, each of them has their own little caveats.

With the sending of secure email comes the receiving of secure email as well. One method used to accomplish this is Secure POP3 (POP3S) and Secure SMTP (SMTPS). Again there are probably as many ways to accomplish this as there are people using it. I am going to look at one way and some of our readers may have some suggestions for others.

POP3S over SSL is one method utilized. Let me preface this discussion with the fact that there are some known vulnerabilities with OPEN SSL so please make sure that you apply patches or fixes as recommended by your OS manufacturer http://openssl.org/news/vulnerabilities.html. With that said, one of the methods that we have utilized is using POP3 over SSL. This a free, open source implementation of Secure Socket Layers (SSL) the same encryption layer that is used for standard, secure Internet based secure e-commerce transactions. This method uses port 995 for POP3-over-SSL and port 465 for SMTP-over-SSL and for those using IMAP it uses port 993 for IMAP-over-SSL communication.

One of the key things that we did is use stunnel to create a secure channel for all of the POP3 data to be exchanged. This stunnel requires a piece of data called a Certificate be generated. This certificate is then used to validate and exchange information from device to device. These certificates can be purchased from providers such as GoDaddy or Thawte
or they can be self generated. Once the certificates are in place the email passed through the ports are encrypted and validated end to end using the key.

This is a very brief explanation of what Ports 995, 465 and 993 are used for. These three ports can take you from a postcard environment to a secured envelope environment with just a bit of effort.

Deb Hale Long Lines, LLC

6 Comments

Published: 2009-10-15

Yet another round of Viral Spam

Reports are coming in today regarding another round of spam attempting to spread malicious programs on machines all over the world.

I just checked my Postini and I too am seeing these emails. Here is the content of the new round:

You have (6) New Message from Outlook Microsoft<br /> <br /> - Please re-configure your Microsoft Outlook Again.<br /> - Download attached setup file and install.<br />

These emails contain an attachment. The ones in my Postini filter contain an attachment with the name install.zip. (This doesn't mean that is the only
name that is being used. )

According to the headers these emails are coming from IP addresses all over the world and are using various mailservers including servers from well
known services like Yahoo and GMail as well as private mail servers at private companies.

In addition to the Outlook spam we are seeing a new influx of IRS spam with an attachment tax-statement.exe, and of course the DHL Service spam.

Yesterday my company got hit with a round of the emails with OWA links. We don't use Exchange for our external email so the link was "broken". We
received a number of phone calls and emails from customers telling us they clicked on the link and it didn't work and asking what they should do now.
Luckily the link was "broke" or we would have had a pretty nasty mess on our hands today. The interesting thing about this was the email was sent to
one email account with "Dear another email account" and the users still clicked on the link. May wonders never cease.

I find this unusual increase in virus spam emails rather ironic beings this is Security Awareness month. Might be a good time to remind your
users about the dangers of clicking on links or attachments that they get in emails. Make sure that they understand what the procedure is for reporting
these emails to your company or your security department.

Deb Hale Long Lines, LLC

3 Comments

Check your email servers - blackholes.us DNSBL is dead

Aaron let us know about a discussion thread on the NANOG mailing list about issues with the blackholes.us DNS block list (DNSBL):

The issue is the maintainer of the blackholes.us DNSBL shut the list down some time back and the IP address space that the DNS servers for it were on was given back to ARIN. That address space has since been re-allocated to a new company and they are getting tired of the continual inbound DNS queries to the IP address of the old server. Apparently they have now stood up a DNS server to answer those queries with a wildcard record that effectively returns "yes, the IP you are inquiring about is a spammer". As a result, lots of mail relays that are still configured to do lookups against this DNSBL are now being told that everyone on the Internet is a spam source.

According to this post in the news.admin.net-abuse.email Usenet newsgroup, the DNSBL was shutdown 2 years ago.

If you are an email administrator, please check your RBLs to see if you are still submitting queries to blackholes.us and remove it from your configurations if you are. You should also review any other RBLs you are using to ensure that they are still in operation as well.

3 Comments

New variation of SSL Spam

We've received numerous emails about this already today. This is an update to a diary we did earlier this week.

The body of the spam today is:

  Dear user of the <some company> mailing service!

  We are informing you that because of the security upgrade of the mailing
  service your mailbox (<user>@<some company>) settings were changed. In
  order to apply the new set of settings click on the following link:

The email contains a link with a file to download.  Some of the files we have seen are:

  settings-file.exe   MD5:  0244586f873a83d89caa54db00853205
  settings-file2.exe  MD5:  e6436811c99289846b0532812ac49986

The files are being detected by some anti-virus software programs at this time as Zbot variants.

Thanks Jon, Frank, iTinker, Nick and others for your reports on this.

5 Comments

Odd Apache/MSIE issue with downloads from ISC

This diary is a bit unusual in that the problem here is very close to home, the ISC/DShield website. But I figure among all of our readers, there may be one who can help. I have seen others describing the same issue, but so far I haven't found a solution.

The problem:

Users who download our log submission client using Internet Explorer frequently receive truncated files. Firefox appears to download them fine. In either case, the server logs a "200" status and the file size in our Apache access log is correct (about 2.2 MBytes). However, the users only receives 200-300kBytes. A packet capture confirms that only 200-300kBytes got transfered. As MSIE starts the download, it does display the correct file size (and the content-length header is correct)

Some of the issues we excluded:

mod_security, firewall, IPS

Also note that the downloads work fine with Firefox, so the server is perfectly capable of sending the file. Any help is appreciated.

Link to the file: http://isc.sans.org/clients/cvtwin-setup.exe

Here is a packet dump of the end of the connection:

IP client.54436 > server.80: Flags [.], ack 193105, win 32850, length 0
IP server.80 > client.54436: Flags [.], ack 646, win 1783, length 1460
IP client.54436 > server.80: Flags [.], ack 196025, win 32850, length 0
IP server.80 > client.54436: Flags [.], ack 646, win 1783, length 1460
IP server.80 > client.54436: Flags [FP.], seq 215005:216465, ack 646, win 1783, length 1460
IP client.54436 > server.80: Flags [.], ack 198945, win 32120, length 0
IP client.54436 > server.80: Flags [.], ack 200405, win 32850, length 0
IP client.54436 > server.80: Flags [.], ack 203325, win 32850, length 0
IP client.54436 > server.80: Flags [.], ack 207705, win 32850, length 0
IP client.54436 > server.80: Flags [.], ack 210625, win 32850, length 0
IP client.54436 > server.80: Flags [.], ack 212085, win 32120, length 0
IP client.54436 > server.80: Flags [.], ack 213545, win 32850, length 0
IP client.54436 > server.80: Flags [.], ack 216466, win 32120, length 0
IP client.54436 > server.80: Flags [F.], seq 646, ack 216466, win 32850, length 0
IP server.80 > client.54436: Flags [.], ack 647, win 1783, length 0

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

15 Comments

Cyber Security Awareness Month - Day 14 - port 514 - syslog

Often times, if hackers or worms break into your computer, they will try to delete the logs on the local computer to help hide their tracks. Having all your computers submit their local logs to a central log server will help you maintain copies of those logs. Even if a bad guy isn't trying to delete your logs, its also a good way to aggregate log data and to review it centrally using tools such as Swatch, Logsurfer or SEC to see if there are unusual events occurring on your systems. These three tools all allow you to build a set of rules to help filter the log traffic. Messages that are 'normal' noise can be ignored and messages that are indicative of unusual activity can generate an alert to notify your admins to review the activities.

There are 3 main syslog packages at this time:

1) syslog - the original syslog program. This only supports sending messages to the central log server over UDP. As such, you have no guarantees that the messages will get to the central server. Because it is UDP based, it is important that you use a firewall to block inbound UDP syslog traffic from the Internet. This is so malicious users can not send in a flood of syslog entries that result in filling up the filesystem on your central syslog server.

2) syslog-ng - in the spirit of Star Trek, this is 'syslog - the next generation'. syslog-ng includes support to submit logs to a central server using TCP, so it can compensate for packets that got lost due to network issues or slow down sending if there is network congestion. syslog-ng also can use supplemental tools, such as stunnel to encrypt the log traffic between the source and the central log server using SSL.

3) rsyslog - this is the latest syslog replacement. It can use TCP as well for more reliable communication. It now has native encryption support built-in, eliminating the need to use a second tool like stunnel to secure the network communication. It can also use MySQL as a storage backend rather than flat text files. This is useful for tools such as phplogcon which can be used to visualize the log data.

For environments with Windows systems, there are add-ons you can install to allow you to submit your various Windows event logs to a syslog server as well. Some examples of these products are winlogd, SNARE, and a Perl module Win32::Syslog.

7 Comments

Published: 2009-10-13

Adobe Reader and Acrobat - Black Tuesday continues

It ain't just Microsoft ... while MS issued a deluge of patches today, Adobe pushes just one, but theirs addresses no less than 29!! gaping holes in one single update. As we reported earlier, at least one of these 29 vulnerabilities is already being actively exploited. So if you are using Acrobat or Adobe Reader, no matter whether on Unix Windows or Mac, you definitely should take a close look at http://www.adobe.com/support/security/bulletins/apsb09-15.html and start rolling the update. If we were in the habit of rating Adobe patches like Microsoft's, this one would be a "Critical"

6 Comments

Published: 2009-10-13

Microsoft October 2009 Black Tuesday Overview

Overview of the October 2009 Microsoft patches and their status.

#	Affected	Contra Indications	Known Exploits	Microsoft rating	ISC rating(*)
#	Affected	Contra Indications	Known Exploits	Microsoft rating	clients	servers
MS09-050	Vulnerabilities in SMBv2 Could Allow Remote Code Execution (Vista and Windows Server 2008 SP2 only)
MS09-050	SMBv2 CVE-2009-2526 CVE-2009-2532 CVE-2009-3103	KB 975517 first mentioned in KB 975497	CVE-2009-3103 is publicly known! see our diary here.	Severity:Critical Exploitability:3,1,1	Critical	Critical
MS09-051	Vulnerabilities in Windows Media Runtime Could Allow Remote Code Execution
MS09-051	Windows Media Runtime CVE-2009-0555 CVE-2009-2525	KB 975682	CVE-2009-0555 known publically	Severity:Critical Exploitability:1,2	Critical	Important
MS09-052	Vulnerability in Windows Media Player Could Allow Remote Code Execution Replaces MS08-076
MS09-052	Windows Media Format CVE-2009-2527	KB 974112	No known exploits.	Severity:Critical Exploitability:1	Critical	Critical
MS09-053	Vulnerabilities in FTP Service for Internet Information Services Could Allow Remote Code Execution
MS09-053	IIS FTP Service CVE-2009-2521 CVE-2009-3023	KB 975254	Exploits Known for both vulnerabilities!	Severity:Important Exploitability:3,1	Important	Critical
MS09-054	Cumulative Security Update for Internet Explorer Replaces MS09-034
MS09-054	Internet Explorer CVE-2009-1547 CVE-2009-2529 CVE-2009-2530 CVE-2009-2531	KB 974455	Exploits known for CVE-2009-2529	Severity: Critical Exploitability: 2,1,2,2	Critical	Critical
MS09-055	Cumulative Secuirty Update of ActiveX Kill Bits Replaces MS09-032
MS09-055	ActiveX Killbits CVE-2009-2493	KB 973525	No known exploits.	Severity:Critical Exploitability: N/A	Critical	Important
MS09-056	Vulnerabiliites in Windows CryptoAPI Could Allow Spoofing Replaces MS04-007
MS09-056	Windows CryptoAPI CVE-2009-2510 CVE-2009-2511	KB 974571	publically known (NULL exploits)	Severity:Important Exploitability:3,3	Critical	Important
MS09-057	Vulnerability in Indexing Service could allow remote code execution if user browses to a malicious page. Replaces MS06-053
MS09-057	Indexing Service CVE-2009-2507	KB 969059	No known exploits.	Severity:Important Exploitability:2	Critical	Important
MS09-058	Vulnerability in Windows Kernel could allow privilege escalation. Replaces MS06-022 and MS08-064
MS09-058	Windows Kernel CVE-2009-2515 CVE-2009-2516 CVE-2009-2517	KB 971486	No known exploits.	Severity:Important Exploitability:2,3,3	Important	Important
MS09-059	Vulnerability in Local Security Authority Subsystem Service Could Allow Denial of Service
MS09-059	LSASS CVE-2009-2524	KB 975467	No known exploits.	Severity:Important Exploitability:3	Important	Important
MS09-060	Vulnerabilities in Microsoft Active Template Library (ATL) ActiveX Controls for Office Remote Code Execution Replaces MS08-015
MS09-060	Active Template Library CVE-2009-0901 CVE-2009-2493 CVE-2009-2495	KB 973965	No known exploits.	Severity:Critical Exploitability:2	Critical	Important
MS09-061	Vulnerabiliites in the Microsoft .NET Common Language Runtime Could Allow Remote Code Execution Replaces MS07-040
MS09-061	.Net Runtime / Silverlight CVE-2009-0090 CVE-2009-0091 CVE-2009-2497	KB 974378	CVE-2009-2497 is public.	Severity:Critical Exploitability:1,1,1	Critical	Critical
MS09-062	Multiple vulnerabilities allow arbitrary code execution. This affect windows, Office (including the viewer), SQLserver and various developer tools. Also affects Forefront Client Security on Windows 2000 SP 4. Replaces MS08-052.
MS09-062	GDI+ CVE-2009-2500 CVE-2009-2501 CVE-2009-2502 CVE-2009-2503 CVE-2009-2504 CVE-2009-2518 CVE-2009-2528 CVE-2009-3126	KB 957488	No publicly known exploits.	Severity:Critical Exploitability:2,2,2,1,2,2,1,2	Critical	Critical

We will update issues on this page for about a week or so as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY

(*): ISC rating

We use 4 levels:
- PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
- Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
- Important: Things where more testing and other measures can help.
- Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

5 Comments

Published: 2009-10-13

Cyber Security Awareness Month - Day 13 Proxies (TCP 3128, 8080 & ......)

Proxy servers are used to manage access to the Internet in companies. It is a tool to check, control, report and otherwise manage staff access to the Internet and is an important tool to enforce policies. There are numerous products on the market, the more well known ones are of course Squid and Microsoft's ISA. They are typically deployed either in the Internal network or in the DMZ or in both zones. The ports used are typically 3128, 8080 and 80, however like any TCP application any port can be used.

Proxies do have their evil twins, Open Proxies. Have you ever had that sinking feeling when looking at firewall rules or web usage and you have noticed that your firewall rule allows the Internet to access your proxy server. Your monthly usage has increased hundred fold, or of the 500 people in your organisation 9,876 of them are currently using your proxy server?

Open proxies, unless deliberately deployed are typically mis-configured firewalls, proxy servers or web servers, but can also be the result of a compromise or malware. It is a convenient avenue to browse anonymously and can be used to propagate things such as undesirable content. Ports 3128 and 8080 are one of the most scanned ports. As many of you will know there are sites that will happily publish the IP address and ports of open proxies.

In many countries the use of an open proxy may be considered illegal as you are using someone else's computer, often without their knowledge. The company/person whose computer is being used as an open proxy may in some jurisdictions also be in breach of some laws, especially if it is being used to propagate child porn or is being used in other criminal activity (Am not a lawyer, so get legal advice if you use open proxies or find one in your network and need to know for sure).

If not patching today, maybe make today your "check for open proxies in my network day".

Mark H

2 Comments

Published: 2009-10-12

Some interesting SSL SPAM

A few people have mentioned (Thanks Luke, Anon, et all) that they have started receiving SPAM messages along the following lines:

On October 16, 2009 server upgrade will take place. Due to this the system may be offline for approximately half an hour.
The changes will concern security, reliability and performance of mail service and the system as a whole.
For compatibility of your browsers and mail clients with upgraded server software you should run SSl certificates update procedure.
This procedure is quite simple. All you have to do is just to click the link provided, to save the patch file and then to run it from your computer location. That's all.

http://evil-link/evil-file

Thank you in advance for your attention to this matter and sorry for possible inconveniences.

Not sure what the evil is, as the links I received have been dead, so if you do receive one of these messages please let us know. If you follow the link, be prepared for surprises and do it on a system that you do not care about (and that does not mean the computer belonging to the annoying fellow/gal sitting two desk away.)

One of the reasons I like this is that the reason to many people it would seem quite plausible, especially if they are running an internal CA at the site. They may have received messages like this from their own support desk. So in a targeted attack this could work quite nicely. The English isn't bad either.

UPDATE

the sample file we received was named patch.exe MD5=9abc553703f4e4fedb3ed975502a2c7a
ZBOT characteristics, so trojan, keylogger, disables AV.
http://www.threatexpert.com/report.aspx?md5=9abc553703f4e4fedb3ed975502a2c7a
If you have a sample with a different hash please upload it through the contact form.

UPDATE 2

In the samples received the URL used in the message typically has a component relating to the organisation itself. e.g. http://something.<yourcompanydomain>.thehostingdomain/somefile.aspx Embedding the company domain will make it look a little bit more legit to the user.

Mark H

11 Comments

Published: 2009-10-12

McAfee Spam Report

In many enterprises, spam prevention and abuse handling is a function of IT Security and less of a business duty for the email system administrators. With that in mind, I wanted to point out something on the operational security front.

Earlier today, McAfee released their October 2009 Spam Report. This report discusses a number of things including the continued increase in pharmaceutical spam, brand abuses, and just the overall sophistication of the spam messages we are receiving today. Throw in all of the phishing scam messages which have been on the increase for the past 3 years, and we can see why the younger generation has all but abandoned email as a communication resource in lieu of more closed systems such as Facebook or twitter. Those of us in higher education has been attempting to cope with this change in communication to varying degrees and expect the corporate world to have to adjust within a few years as well.

So..... thought I would point out something that may be useful for situational awareness purposes, or to at least explain to the C-level people why the spam filters missed a number of spam messages recently.

Scott Fendley ISC Handler

0 Comments

Published: 2009-10-11

Cyber Security Awareness Month - Day 12 Ports 161/162 Simple Network Management Protocol (SNMP)

SNMP has to be one of my favourite protocols when doing internal pentesting. Mainly because I know that there will be a bunch of devices that are configured to use it, in fact almost everything connected to the network that isn't a workstation is likely to have SNMP open. Secondly because the "password" or more correctly the community string is likely to be "public". If it isn't then it is often trivial to find. Once you have the community string, then it is a just a matter of asking the devices nicely to give up their configuration details and you quickly have a good picture of what the network looks like. If you are lucky you can reconfigure the devices as well.

SNMP is used to monitor network connected devices. It consists of a manager and a number of agents. The manager at regular intervals polls the agents on port UDP/161 and queries the Management Information Bases (MIB) for the device. The MIB is effectively a hierarchical database structure for information on the device, e.g. serial numbers are in a specific location, nic statistics, etc.

SNMP-TRAP allows the agent to send information about itself to the manager on port UDP/162. TCP can be used for both 161/162, but UDP tends to be more common.

Typically the agents are configured in read-only or read-write mode. The difference between the two is determined by the community string used.

There are several versions of SNMP V1, V2c and V3. V3 introduces encryption, message integrity and better authentication than can be provided by the community string.

There are a few challenges when using SNMP.

With the exception of V3, information is exchanged in clear and can be sniffed.
All versions are susceptible to password guessing attacks.
Whilst V3 is the right version to use, many devices are only capable of using V2c or even V1 so you have to live with the insecurity
When UDP is used, packets can be spoofed (what will the effect be on your SNMP-TRAP server when it receives thousands of TRAPs per second?)

There have been a few security advisories relating to SNMP over the years, it tends to be an internal issue. However if you accept SNMP queries from the internet you may be leaking more information than you thought. In fact in a previous life we used "public" IP addresses on an internal network segment. When mapping the internal network using SNMP, using one of the monitoring tools and due to a configuration challenge (yes we let SNMP out of the network), the SNMP requests didn't end up on the internal network, but on the Internet. The following Monday morning we had a great network map of a network somewhere in Europe. I'd like to think people have learnt since then, but ....

For more information have a look at the wikipedia entry which is quite good or you can always read the many RFC associated with SNMP (1155, 1156, 1157, 1441, 1213, 3410-18, 3584 & 3826).

Mark - Shearwater

2 Comments

Published: 2009-10-11

Cyber Security Awareness Month - Day 11 - RPCBind aka Portmapper

As most of our regular readers are aware, this is Cyber Security Awareness Month and the ISC handlers are writing diary entries about securing various ports and services. For the die hard security professionals, this month is nothing more than a review of things you have learned over the past 10-20 years. For those new to information security, it is our hope that you learn more about the various ports and services which are commonly used on networks. As the old adage states, those who do not learn from the past are doomed to repeat it. It is my hope that you as our reader will learn from the mistakes of our collective past so that as an industry we don't have to repeat things (as often at least).

To that end, let me share a bit of a story (and personal history).

In my life prior to becoming an InfoSec professional, I was a student worker who functioned as Unix systems administrator over a small lab of Solaris workstations. As the case with many of student workers, our work space was usually some closet, or cubical where they could stash us which had 3 things, a 10bT ethernet jack, a phone line run to it, and power. My supervisor was located in a building halfway across campus (a good 10 minute walk) and my nearest student co-worker was at least 2 or 3 buildings away. One of the most frustrating mysteries of my job was that my supervisor seemed to be psychic. No sooner than I sat down at my little workstation, he would call me with a list of things I needed to do. If I was running late from class, or left my office early, he seemed to have an uncanny awareness of that fact and I would hear about it rather quickly.

As a part of this desktop Unix support team, one of the first tasks was to install our very own workstation from the ground up (with some documented guidance others had developed). I got to have the full administrator experience of setting up accounts, and monitoring the activity of those accounts, compiling and installing new software, updating the computer, and just about everything else you could imagine. The only thing I had to do is provide the root password to my supervisor usually in a sealed envelope that he would stash in one of many books sitting on his bookshelves.

Even in these early days of my career, I had already begun that paranoid security mindset that I believe our field really requires. At the time I could tell you every application I had installed, what services I had running from the /etc/inetd.conf, and which of my users had logged in recently and what they had done. I turned on all of the logging features of which I was aware, and reviewed these audit logs routinely. So the peculiar thing is that my supervisor never needed to telnet (these were the old days before SSH was prevalent) into my workstation to check up on me. The question that haunted me for so long was how he could detect that I was in my office without any of the modern avenues available today (such as a central authentication system, door logs, hallway cameras and similar).

At some point, he revealed to me how he seemed so psychic to all of us student workers: PerfMeter. Perfmeter is a tool which uses the Unix RPC (remote procedure call) services that ran on Solaris machines which would provide a number of statistics about the system including CPU usage. At the time, the default screen savers under Solaris X windows would either be very heavy on CPU cycles, or didn't use much of anything in comparison to when you were on the workstation. And as Perfmeter could communicate with a remote system without the need of authenticating (!!!) and left no audit log entries (!!!) of this activity occurring, my supervisor just had to configure a graph for each of the student workers computers and know if we were at work or not. And as a consequence of the lack of any true security perimeter, any attacker in the world could potentially use this or other RPC based applications to gather intelligence on system administrators and the systems they maintained with little to know hurdles to speak of.

PerfMeter is only one of many thousands of applications/services which communicate via RPC calls which initially use TCP or UDP port 111. RPC is/was a very powerful technique for constructing distributed, client-server applications and is based on the notion that a called procedure need not exist in the same resource space as the calling procedure or application. By using RPC, the programmer of these distributed applications could avoid the details of the interface with the network (and consequently avoid making as many programming mistakes in the networking code which was so prevalent at the time).

In many cases when a client makes an RPC call for a given program, it will first connect to the rpcbind or portmapper service (tcp/udp 111) on the destination system to determine the ultimate port where the request should be sent. The active port 111 will have a list of all active services, and tell the requesting client were to connect. However, infosec professionals should know that under some versions of Unix rpcbind not only listens on the TCP/UDP port 111, but it also listens on UDP ports greater than 32770. The exact port number is dependent on the OS release and architecture. Thus, packet filtering devices, router ACL blocks, and firewalls that are configured to block access to rpcbind/portmapper at only port 111, may be subverted by sending UDP requests to rpcbind listening above port 32770. This vulnerability may allow an unauthorized user to obtain remote RPC information from a remote system even if port 111 is being blocked.

To finish a part of the story, I eventually found that Wietse Venema (author of SATAN, TCP wrappers, and other security tools) had developed a replacement to the native rpcbind/portmapper program that would correct two of the main issues I had with it at the time: access controls and logging. With this tool, I was able to at least attempt to thwart the attacker (my supervisor) until told otherwise, and limit the amount of data my workstation was allowing out.

While Unix based RPC doesn't seem to be as prevalent today, I do expect that this construct can and will be used in the future in new and different ways. We all have seen or heard of stories where there is an intrusion which involves some legacy application which was not properly secured. Chances are some of you may have one of those applications running on the interior of your network.

Here are some recommendations I have for securing these applications. If you have other suggestions, please share via our contact form.

1) Inventory your servers to see if any of them are listening for TCP or UDP port 111 using a tool like nmap. Also, check for high UDP ports such greater than 32770. Alternatively, get the server admins provide the output from lsof for UDP and TCP ports which are listening.
2) For each of these servers, enable the host based logging which may be available.
3) Verify that this log data should be flowing to your centralized log server or Security Event Management system.
4) Configure the host based access control to limit what computers or networks can do RPC calls (and don't forget that localhost may need to be allowed for some intra system communications). Most modern Unix/Linux based systems have incorporated Venema's tcp wrapper access control framework which makes this reasonably easy today.
5) As a defense in depth measure, make sure that your router ACLs or Firewall rules limit your exposure from outside of your organization to the portmapper service port.
6) If a server has no need for the service such as NFS, NIS/NIS+ or legacy applications which uses RPCbind, then shut off the service.
7) Solaris 10 systems can enable the host based TCP Wrapper support by running the following command:

# svccfg -s rpc/bind setprop config/enable_tcpwrappers=true
# svcadm refresh rpc/bind

So readers, what other recommendations do you have in securing the RPC protocol?

Scott Fendley, ISC Handler on Duty

1 Comments

Published: 2009-10-10

Cyber Security Awareness Month - Day 10 - The Questionsable Ports

The Internet Storm Center is focusing on IP ports for the month of October. I am going to continue the theme, but with a bit of a twist. I am going to talk about a few of the ports that are usually not desirable to appear in a traffic analysis. There are many more than I could list, the majority associated with malware. But not all of them. Here we go:

1214 - Limewire/Kazaa (A Peer-to-Peer application. Not by definition malware, but not something desirable in an enterprise)

2773 - SubSeven (Trojan)

5631 - pcAnywhere (A commercial remote control application)

1863 - Numerous Microsoft applications

I want to emphasize that these listed are not necessarily bad. The point here is awareness. Knowledge, and management, of the ports required and permitted in the enterprise, and at home, will lead to an overall improvement of the security posture of a network. This is where syslogs, traffic analysis, and documentation will tie everything together.

I welcome any and all thoughts, comments, questions, queries, concerns, etc. I will post updates to this story as comments come in to the ISC.

tony d0t carothers @ isc d0t sans d0t org

0 Comments

Published: 2009-10-10

User Notification for Possible Infected Systems

One of our readers, Roy, came across this article from Yahoo! this morning reporting that Comcast is planning to enlist it's customers help in the fight against botnets by using pop-up alerts. Comcast's general idea is that, if Comcast notes traffic associated with known botnet activity, a pop-up will appear on the user's computer. The article gives the full details as reported by the Assosciated Press.

The last paragraph, from an overall security perspective, is the most concerning to me, and that is the use of hoax popups and sites. I quote "Phil Lin, marketing director at network security firm FireEye Inc., said hackers could mimic Comcast's pop-up banner or the confirmation ads. And unsuspecting customers wouldn't know they should expect to see a confirmation from Comcast in the first place." We know it is only a matter of time, and my guess is it will be a very short time, before the botnet farmers start making use of hoax notification pop-ups and sites.

The bottom line: Good security practices up front, solid software and applications, and user awareness would almost eliminate the need for any effort of this type.

3 Comments

Published: 2009-10-09

AT&T Cell Phone Phish

Alan tells us that several AT&T cell subscribers have just received a text message, which instructs them to call a toll-free number XXX-XXX-7649 to resolve a problem with their account. When called, a voice menu harvests their credit card information.

An interesting delivery mechanism for an old-hat phish, which we're all used to seeing in our email inboxes - now bright-shiny-new as a text message - nice find Allan!

Johannes tested this with the 4111 1111 1111 test card number, which the phish menu verified correctly. Subsequent tests indicate that a random 16 digit number is initially accepted by the voice menu, but fails verification at the end of the input process. This indicates that the menu is actually verifying and processing the CC numbers correctly, and is most likely processing (evil) transactions in close to real-time.

Always interesting to keep tabs on what evil lurks out there !

5 Comments

Published: 2009-10-09

THAWTE to discontinue free Email Certificate Services and Web of Trust Service

Arno writes in to tell us that Thawte will be discontinuing their free E-mail Certificates and email cert "web of trust" service, as of Nov 16, 2009. They are offering a free one-time migration to a 1 year Versign certificate services subscription (which is is a chargeable thing after your first year runs out).

Information on the discontinuation and the migration can be found here ==> https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=AD196&actp=LIST&viewlocale=en_US
and here ==> https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO12704

4 Comments

Published: 2009-10-09

Cyber Security Awareness Month - Day 9 - Port 3389/tcp (RDP)

Feel free to comment on this diary entry - we’re interested in issues or resolutions you may have had involving the RDP protocol, Terminal Services client and server applications, as well as any questions you may have regarding this diary entry. You can use the comment button at the bottom of this article.

Microsoft's RDP (Remote Desktop Protocol) and it's associated "terminal service" client and server apps have been widely used since Windows 2000 days for Windows server administration. RDP gives delivers the server's complete remote desktop to a client. RDP has been improved over time, and is now pretty much the de facto standard for remote administration in most datacenters.

In more recent times, VDI (Virtual Desktop Interface) implementations often use RDP to deliver the desktop from a VM to thin clients or PC's, in an effort to centralize control and minimize administration requirements for client desktops. This has resulted in more widespread use, as well as improvements to the protocol especially around the delivery of graphics and performance in high-latency situations.

The perception has always been that RDP offers a secure delivery of information, as Microsoft publishes detailed information of it’s encryption settings. The default setting is now “high”, which means 128bit encryption (using RC4)

However, there’s a problem with RDP – by default the certificate used for encryption is signed by an RSA private key, which is then stored statically in the file mstlsapi.dll, which every Windows client and server has in it’s base install! This was originally discovered by Erik Forsberg in 2003 (http://www.securityfocus.com/archive/1/317244 ), and documented further at http://www.oxid.it/downloads/rdp-gbu.pdf (amongst other places).

This means that in a default installation, a Man-in-the-Middle (MITM) attack can intercept the exchange of RDP encryption information, substitute it’s own (correctly signed) SSL information to both the client and the server, and decrypt the entire session, all without the “encryption alert” message showing up at the client!

Even if that were not the case, the default installation for Terminal Services client on XP does not notify you if the server certificate does not "match". Check for yourself - open the terminal services client, choose the "Advanced" tab, then check the "verification policy" value - youi'll see that it's set to "Connect and don't warn me"

What does this mean to me?

What this means is that if the default Windows installation is taken, and no further protections around encryption are implemented, that RDP is easily compromised. This is normally done by capturing an RDP login exchange, usually using a Man-in-the-Middle attack, then decrypting the captured packets to arrive at the password. CAIN (www.oxid.it) does a great job at this task. Describing an attack in theory is great, but I find that people don’t often take it seriously until the SEE it work in their environment. For this reason, we’ve attached a short video of such an attack, with a brief description of how MITM attacks. This attack works even if you change the “Server Authentication Verification” discussed above.

When I discuss this with people, they often don’t realize just how large a security risk this is – until they see it for real that is. This video shows just how easy it is==> http://isc.sans.org/diaryimages/rdp-mitm-mpg.html .

There's a brief explanation of how Man in the Middle via ARP cache poisoning works, but the emphasis is on the RDP stuff, and on how to use CAIN to get the goods – in an internal security assessment for instance. Just be sure that if you try this at home, that your laptop has enough horsepower to “keep up”. If your laptop chokes during the attack, remember that you’ve poisoned the ARP cache of 2 or more hosts (your DC is one of them maybe), and the default ARP cache timer is 4 hours!

In a larger sense, what this should mean to us is that the default installation of most things (including Windows) is almost never the right choice for security. Products ship so that people can install them with limited training and be still successful. This is true of Windows, most Linux distributions, OSX, pretty much everything. After installing an operating system for business (or personal) use, it’s always a good thing to reference that vendor’s security best practices. Googling the vendor name plus “hardening guide” is often a good start. Other references that may be helpful are sites like the “SANS Top 20” ( http://www.sans.org/top20/ ) or the benchmarks at the Center for Internet Security ( http://www.cisecurity.org/ ).

How can I fix RDP in my Datacenter? Do i need to stop using RDP?

The good news is that the RDP protocol, as well as Microsoft’s Terminal Services client and server applications are very well constructed, and can be secured using industry-standard methods, methods that you are probably already using for your corporate website or wireless infrastructures. Microsoft has really good documentation on using a PKI (Public Key Infrastructure) to use trusted authorities to secure RDP using TLS (Transport Layer Security). You can find one such document (which references other docs) here ==> http://technet.microsoft.com/en-us/library/cc782610%28WS.10%29.aspx

Can I prevent Man in the Middle Attacks?

You can certainly make them more difficult by configuring you switches correctly – look for an isc diary on Layer 2 protections coming soon.

4 Comments

Published: 2009-10-08

New Adobe Vulnerability Exploited in Targeted Attacks

Adobe's PSIRT (Product Security Incident Response Team) published a new blog post today [1]. The post reveals that a critical vulnerability, CVE-2009-3459, is now being exploited in the wild in targeted attacks. The vulnerability affects Adobe 9.1.3 on Windows, Unix and OS X. However, the exploits have been limited to Windows so far.

An update scheduled to be released on Oct 13th should fix the problem. Until then, Windows users are advised to enable DEP. Anti malware vendors have been informed by Adobe.

This vulnerability does not require Javascript. If you disabled Javascript in the past, it will not protect you in this case. Another workaround I found helpful: You can "clean" PDF documents by first converting them into another format (like Postscript) and then back into PDF. However, this is not 100% certain to remove the exploit and you may infect the machine that does the conversion as it will likely still use the vulnerable libraries to convert the document. But the likelyhood of this happening is quite low.

[1] http://blogs.adobe.com/psirt/2009/10/adobe_reader_and_acrobat_issue_1.html

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

10 Comments

Published: 2009-10-08

Cyber Security Awareness Month - Day 8 - Port 25 - SMTP

My personal favorite port is port 53, but well, it was already taken. So I am going to cover port 25, my least favorite port :)

Port 25 is used by mail servers to receive e-mail. E-mail in itself is of course a mixed blessing. Spam levels in the 90% range make it a less and less useful business tools. There is a lot of history involved here, and SMTP wasn't the first "E-Mail" protocol. Before SMTP became popular, protocols like UUCP (Unix-to-Unix-CoPy) were used to exchange email. SMTP in some ways extends these older protocols and inherited some of the properties.

For a full description of SMTP, start with RFC821 (http://www.faqs.org/rfcs/rfc821.html). But RFC821 is just the start. Later RFCs expand on it substantially and you will need to understand them to fully appreciate how today's e-mail servers work. Let me try to assemble a quick SMTP primer here.

First of all, the mail client will connect to the mail server, the mail server will identify itself with a line like:

220 mailserver.example.com ESMTP Postfix

The number in the beginning is the important part, the rest is mostly ignored. "220" means the service is ready to receive your spam. Next the client has to identify itself. There are two ways this may happen. The old way (RFC821) is to send a "HELO" message like:

HELO mailclient.example.com

However, modern clients will typically use "EHLO" instead of "HELO". EHLO is defined in RFC 1869. Sending an "EHLO" will signal to the server that your client understands the extensions defined in RFC 1869.

The servers response to a HELO or EHLO will be a "250" code (if there wasn't an error).

250 zimbra.den.giac.net

For an EHLO, additional '250' lines will be returned listing the capabilities of the server. At this point, we do have an established connection and are able to send our first e-mail. The e-mail itself consists of 3 parts:

- an envelope. This is typically not part of the e-mail, but indicated the From and To address to the mail server. The From and To address in the envelope can be different from the From and To address used in the header of the message

- a header. The header includes typically a Subject/From/To and other fields.

- a body. Delimited from the header by an empty line you will find the body of the message.

But well, you probably knew all of that. Lets talk about a few more interesting features:

STARTTLS: This scheme, if both sites support it, can be used to negotiate an SSL connection on the fly. RFC 2487 will tell you more about it. But here the details: The connection starts as outlined above. But after the initial EHLO/250 exchange, the client will send a STARTTLS command. This will lead to an SSL connection being established. The SSL certificate may be used for authentication purposes as well as encryption in this case.

Message Submission: RFC 2476 outlines a new method to submit messages which is widely implemented. The basic idea is to distinguish between message forwarding, and injection new messages ("message submission"). RFC 2476 suggests the use of TCP Port 587 to submit messages.

Non Delivery Receipts: This is a sore point in many mail server configurations. There are two ways to indicate that a message is not deliverable. As the server receives the envelope, it will check the "To" address, and reply with an error message before accepting the e-mail. This is preferred as it cuts down on network traffic and non-delivery receipts beind sent to the wrong people later. However, it requires that the mail server knows all the users that are deliverable. For a simple relay server, this can be hard to figure out at times.

lots more to tell you about SMTP, port 25 and why I don't like e-mail. But maybe that will be a later diary.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

1 Comments

Published: 2009-10-08

Firefox Plugin Collections

Our reader Mark send us a link to his firefox "Security Suite" https://addons.mozilla.org/en-US/firefox/collection/securitysuite .

Mozilla started offering the ability to setup these collections to make it easier to share sets of plugins like that. Our handler Swa got inspired by Mark's submission, and setup his own https://addons.mozilla.org/en-US/firefox/collection/isc

I think this is a great idea. And I am wondering what plugins our readers would recommend for a suite like this. I can see three different suites:

- Home user security suite
- Security professional suite
- Pentesting suite.

Let me know which tools you would add to either one of them, and I will publish the top 5 plugins in each category (and maybe even setup the corresponding suites)

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

10 Comments

Published: 2009-10-07

Cyber Security Awareness Month - Day 7 - Port 6667/8/9/7000 - IRC: is it evil?

IRC. Internet Relay Chat, commonly found on ports 6667,6668,6669, and 7000, but really, found on most any port.

My question is, is it evil? Now, I've worked at some places in the past where IRC was generally forbidden, viewing that it was pretty much an evil thing, only "hackers" used it, and was a bad place to download "warez". (Yes, these words are put in quotes because they were actual words spoken to me, when I asked the question "Uh, Why?")

IRC is a very well documented (RFC here) "chat" protocol allowing for any of hundreds upon hundreds of pieces of client software to interact with IRC servers (or networks of servers such as freenode, efnet, or dalnet) in order to enter "rooms" or "channels" in order to talk with other members of the channel or room. Most of you know this.

However, there became another use for them several years ago, one of a Command and Control or "C&C" type of technology, where malware that was placed (or downloaded and ran) on a machine on your local network connecting outbound, "beaconing" back to the C&C server (generally just an IRC channel with a password) so that the Master of the malware could control the other computers.

This became known as a botnet. You may have heard of them.

(Now, I am sure the term "botnet" was used long before IRC was being used as a C&C, but you get my point, in fact, I know it was, but you get my point.)

Of course over the years, botnets have become more sophisticated, by using things like SSL and http instead of IRC, but there are still a lot of botnets out there that use IRC for C&C.

Where I used to work, and also in my present job (Sourcefire, makers of Snort) we used to find these botnets by using the IRC rules that are found in the chat.rules file. The rules that are in the chat.rules files are bound to the standard IRC ports, however, and as I previously stated, IRC, especially C&C "covert" channels of IRC traffic, goes out over any port.

I've seen C&C on port 80, port 53, you name it, 23, 21.. you get the point. So the easiest way I found to track these IRC network connections is by removing the port restrictions on the IRC rules in the chat.rules file, and replacing the ports with an "any" statement. (Of course, I am referring to Snort syntax here.) Allowing the rules to trigger on IRC on any port.

Things to keep in mind about this very simple method of finding IRC on the network, if you allow IRC on your network, you are going to get tons and tons of alerts...

... however, if you do NOT allow IRC on your network, and you find it, you are either finding someone who is violating policy (generally something you'd want to do), or, something worse. Hopefully not one of these simplistic C&C "covert" channels, if you find these examples (usually easily identifiable by reviewing the Snort logs and NOT seeing a conversation, but seeing commands and passwords being issued), start noting the IPs that are in the alerts on your network, and start cleaning!

I generally don't feel that IRC is a bad thing, if used responsibly. If IRC is allowed on the network, then finding those botnets can be tricky (I would start by suppressing freenode, dalnet, etc servers in your threshold.conf file), and it might take more work, but the benefits of it will show themselves in the end.

-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler

7 Comments

Published: 2009-10-07

Spam rate increase is seen

Thanks to a reader (Thanks Bob), who wrote in this morning asking if we have seen an increase in spam lately, I can personally confirm that yes, I have seen more spam in my inbox lately.

Bob sent us a couple interesting graphics, the first being a graph of how much of a spam increase there has been recently:

Secondly another graph he sent in was an interesting correlation. It was how many viruses have been blocked by ClamD.

As I said, I've noticed a big increase in spam lately in my own personal email as well.

What about the rest of the readers? Have you guys experienced similiar?

-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler

13 Comments

Published: 2009-10-06

Cyber Security Awareness Month - Day 6 ports 67&68 udp - bootp and dhcp

DHCP is a very commonly used protocol for the automatic assignment of TCP/IP configuration options. DHCP is defined in RFC 2131. "The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior of BOOTP relay agents [7, 21], and DHCP participants can interoperate with BOOTP participants [9]." DHCP extensions for IPv6 is defined in RFC 3315.

Common values include:

IP address
Subnet mask
Default gateway (router)
DNS servers
DNS domain name
Lease time
802.1Q VLAN ID
802.1P L2 Priority
Bootfile-Name
TFTP Server IP address

DHCP is not without its issues, here are some of them:

DHCP is a UDP based protocol and is easily spoofed
DHCP lease exhaustion/starvation Denial of Service attacks
Rogue DHCP server responding to clients, the sky is the limit with this attack
Spoofed RELEASE packets Denial of Service attacks
DISCOVER and REQUEST are broadcast, everyone hears them and anyone can respond
No concept of authentication
Unless Layer2 security is enforced rogue clients get a lease too
Assigning rogue DNS server IPs to clients, allowing pharming attacks among others
Vulnerabilities in the DHCP client, some allowing remote arbitrary code execution
Vulnerabilities in the DHCP service, some allowing remote arbitrary code execution

Please contact us if you have any comments or would like to add to this diary entry.

A reader wrote in "PiXiE uses Wake-On-LAN to turn on machines after they power down, then feeds them a rootkit over BOOTP when they try to network boot (many systems automatically try network boot when woken-on-LAN." A presentation can be found here: PiXiE: A Self-Propagating Network Boot Virus for Windows

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

2 Comments

Published: 2009-10-05

Time to change your hotmail/gmail/yahoo password

Microsoft has confirmed that thousands of Windows Live accounts have been compromised with their passwords posted online. Mainstream media such as the BBC are also carrying the story. Some information is posted here.

UPDATE: Gmail and Yahoo are also affected by the compromise. Change all passwords on any of these popular webmail sites.

Some does and don'ts:

Do change your passwords on a regular basis (every six months or so)
Do use long complex pass-phrases rather than passwords where you can
Do change all of your passwords if you notice something suspicious
Do take identity theft seriously
Do use up-to-date anti-virus and a firewall
Do NOT click on links in emails, ever
Do NOT use the same password at multiple sites

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

14 Comments

Published: 2009-10-05

Cyber Security Awareness Month - Day 5 port 31337

Backdoors and malware and trojans oh my!

Post 31337 (tcp or udp) is not an officially assigned port according to IANA. Most /etc/services files do not reference it. So why pick what seems to be an obscure port that does not have a protocol associated with it to discuss as part of Cyber Security Awareness Month? If you use a popular search engine 31337 tends to return references to 31337 being an alternate spelling for Eleet (or Elite), and possible infections of a backdoor trojan which listened by default on this port. Back Orifice is not exactly new, originally released in 1998, it's successors such as BO2K have been updated somewhat. Most anti-virus engines will classify Back Orifice as malware and attempt removal. Some IDS engines will still alarm on traffic going to or from once popular typical trojan ports.

One part of the discussion of port 31337 could be the futility of alarming on any particular tcp or udp port at all. In 1998 BO had the ability to change its default listening port to anything at all. Any service in fact can be made to listen on pretty much any port. Without looking at the payload of the traffic you have no idea what is happening, whether it is a firewall or an IDS triggering on a 'suspicious' packet.

Trojans have not gone away to be a footnote in the history of InfoSec, they have evolved.

Please contact us if you have any comments or would like to add to this diary entry.

Update1: Dan wrote in to remind me that port 31337 is also the default listen port for Ncat, the netcat replacement from the Nmap team. Thanks Dan!

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

1 Comments

Published: 2009-10-04

Samba Security Information Disclosure and DoS

Samba released several updates to fix some security vulnerabilities. Anyone running Samba should take a look at each of the bulletin below and seriously consider upgrading which can be downloaded here.

References:

Information disclosure by setuid mount.cifs - affecting all versions

Remote DoS against smbd on authenticated connections - affecting all versions

Misconfigured /etc/passwd file may share folders unexpectedly - affecting version > 3.0.11

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org

0 Comments

Published: 2009-10-04

New ISC Feature: One Liner "event notes"

We are going to introduce a new feature this weekend: One liner "event notes". These notes are intended for cases in which we try to point out something briefly, which doesn't deserve or need a full diary. For example an outage, or a patch for some software.

Right now, the notifcations are not sent for these "one liners". In the future, I may add an option to send them.

Please use our comment form to report problems with these one liners. I am also interested in anybody who has issues using the OpenID login. Right now, I am aware with some providers having problems, but I need a few more samples. If you attempted to use an OpenID, but it failed, please let me know the Open ID you used and how it failed.

Thanks!

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

2 Comments

Published: 2009-10-04

Cyber Security Awareness Month - Day 4 - Port 20/21 - FTP-data/FTP

First proposed in April 1971, the File Transfer Protocol is one of the oldest protocols of the Internet. According to RFC 959, "The objectives of FTP are 1) to promote sharing of files (computer programs and/or data), 2) to encourage indirect or implicit (via programs) use of remote computers, 3) to shield a user from variations in file storage systems among hosts, and 4) to transfer data reliably and efficiently." The FTP protocol is somewhat complex and uses three methods to transfer files. The one thing to remember is the choice of connection method is initiated by the client and the server has the option to refuse to use it at which point the connection will fail.

Active FTP Method

In this method, the FTP client opens a dynamic port and the FTP server connects to the client (the server is the “active” participant) on a random port chosen by the client who waits for a connection from the FTP server. Since the client decides the method, it will send a “PORT” command containing the IP address and port where the server needs to connect.

When you examine a packet trace, you will notice the client sending the information to the server with the IP and Port like this (h1,h2,h3,h4,p1,p2) – where the client sends the server the IP address and the port. For example, the client sends IP and Port (192,168,1,102,4,2) indicating the client is listening on IP 192.168.1.102 using TCP port 1026 ((4 * 256) + 2)) after which the transfer will start using the new port.

Passive FTP Method

In this method, the FTP client connects to the server on a dynamic port chosen by the server. Again, since the client decides the method, it will send a “PASV” command to initiate the Passive transfer and the server respond with something like "227 Entering Passive Mode (192,168,60,11,192,52)"by sending a message containing the IP address and port (using the same syntax used in Active FTP).

Extended Passive Mode - IPv6 and NAT

With the release of RFC 2428 in September 1998, the Extended Passive Mode was added to IPv6 and NAT as another method for FTP transfer. In this mode, the FTP server operates exactly the same as passive mode. The only difference is that it only transmits the port number (not broken into high and low bytes) and the client is to assume it connects to the same IP address it was originally connected to.

The basic concepts of FTP transfer is where the client opens a control connection to the server on TCP port 21, and specifies a source port as the source to which the FTP server should respond (IP and Port information). The FTP server sends its response using port 21. At this point, the server and client negotiate the data transfer parameters. The FTP server opens a second connection for data on port 20 to the client. The client will then responds on the data port to complete the connection and data transfer begins.

This protocol is insecure for transferring files because everything is sent in the clear where user names, passwords, FTP commands and transferred files can be captured using a packet sniffer. An alternative is to use the Secure File Transfer Protocol (SFTP) to protect the information in transit.

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org

1 Comments

Published: 2009-10-03

Cyber Security Awareness Month - Day 3 - Port 5900 - VNC

Friendly uses

tcp/5900 is used by VNC, a platform independent desktop sharing and remote control application. VNC is hugely popular and also used for helpdesk/remote support in many large organizations.

Nefarious uses

Well, it is a *remote control* tool. There's probably a bad guy or two out there who likes to remote control your PC while you are in the middle of an e-banking session. And there's even more bad guys out there who are too incompetent to work with a command line, and prefer to have their hacked victims accessible over the GUI. Yes, VNC is being used by Trojans, Backdoors and Hackers alike. If you ever find VNC on your PC and it wasn't you who put it there: Worry. Worry more. Then, re-install your PC from scratch.

As the DShield graph for port 5900 shows, there is a lot of scanning going on for tcp/5900, which is the VNC standard port.

The scanning seems to have two main purposes:
(1) To find VNC servers that can be breached by a brute force password guessing attack
(2) To find VNC servers that are still vulnerable to one of the more serious holes (like CVE-2006-2369)

As a reader commented in one of our more recent diaries on the subject, the best defense is not to open VNC up to the world in general. Tunneling through SSH or IPSEC improves VNC security quite a bit. If you need to keep it exposed to the outside, use the latest version and pick a loooong password. It also doesn't hurt to move it to a port other than 5900. While this is mere security-by-obscurity, and won't help against a targeted attack, it DOES keep all the scanners away who are just trolling for a target of opportunity.

Note that VNC is also using 5901..5903, depending on how many screens there are, and also uses tcp/5800 to allow a clientless (Java in browser) connection to a VNC server. Last but not least, tcp/5500 is used to "shovel" a connection from a server to a viewer running in "listening mode". The latter mechanism is hugely popular among the bad guys, because there are still way too many firms who have a firewall with a "permit anything from the inside going out" rule. Once a bad guy manages to subvert (virus, hacking) a server on the inside, he still can't get to it with an inbound connection on tcp/5900, but he often can "shovel" a tcp/5500 inside-out back to his listening VNC viewer. Metasploit also has a couple of lovely payloads to chose from that facilitate this sort of thing.

All the ports mentioned above are the standard ports used by VNC out of the box. A VNC server is just as happy on Port 80 as it is on 5900 though, so while scans for tcp/5900 are usually indeed looking for VNC, you should have your IDS on the look-out for VNC traffic on ANY port. Emergingthreats has a couple of nice Snort rules for VNC traffic.

1 Comments

Verizon New York area issues

A number of readers in the last 20 minutes have been indicating that there has been an outage with Verizon in the New York area. Service appears to be recovering, and some internet health monitoring sites are showing latency entering and exiting the Verizon hub in Boston.

Nanog are reporting a few people experiencing connectivity issues in the NY US area.

If you have any information on what happened, let us know and we'll update this diary with the news.

Update: Verizon have indicated via Twitter that:

"a router responsible for peering in the Northeast failed. It was reset and traffic should be coming back."

Update 2:

Verizon have now posted a blog detailing the event in addition to their continuing updates on Twitter

Steve Hall

0 Comments

VMware Fusion updates to fixes a couple of bugs

VMWare have informed us that an update is available for their Apple Mac version of their VMWare environment, VMWare Fusion.

The update fixes a vulnerability found in all versions of VMWare Fusion, so if you use this product, it is time to update. A vulnerability for one of the issues has been published.

The published vulnerability apparently produces a remote shell with root privileges but I have not tested it at this time.

The exploit writer comments:

"The vmx86 kext ioctl handler permits an unprivileged userland program to initialize several function pointers via the 0x802E564A ioctl code. These function pointers are later used from several reachable locations within the driver, one of which is called immediately after initialization."

0 Comments

New SysInternal fun for the weekend

A whole raft of new SysInternal goodness has been released just before the weekend so we have new versions of our toys to play with over the weekend.

The SysInternal blog has all the news but in summary, there are updates to LiveKd, BgInfo, ProcDump, and Autoruns.

Mark also blogs about a couple of interesting issues.

Thanks to Roseman for the heads up, and the follow-up e-mail.

1 Comments

New version of OpenSSH released

The guys and gals over at OpenSSH have announced that a new version has been released. This is version 5.3, and its also the 10th Birthday version of the stalwart of secure communication over TCP port 22.

Details of the release can be found in the release note and should be on the mirror servers soon.

The release note shows a couple of general bugs, and a few platform specific ones.

Enjoy, and remember to test your deployment!

0 Comments