Clam AntiVirus vulnerability

A vulnerability was discovered in the popular open-source anti-virus
scanner Clam AntiVirus. Many people are running this on their mail
servers, so make sure that your e-mail administrators update to the
latest version. Vulnerability details here:


http://www.osvdb.org/displayvuln.php?osvdb_id=18259

Con-fu

Many of you might be attending the security conference Black Hat and/or
Defcon this week. I decided that it might be good to put up some tips
for computer security when attaching to the wireless networks there. Of
course, you can use these tips for any other untrusted network. Feel
free to send us your tips also.



I have a couple of Linux machines running at my house. So I have found
that the safest way to hit the Internet is to tunnel everything through
SSHD at my home network.



My first suggestion: if you absolutely don't need to connect, then don't
take the risk. Just keep your laptop in your hotel room for emergencies
and you won't have to deal with the inevitable frustration of the
wireless network going down. Yes, you may have some envy as you see
everyone else geeking out in the hallways. But you will have the added
advantage of being unencumbered as you head to the bar/pool/casino
tables later.



Second major point: if you have a Windows laptop that is work-related,
you may want to seriously consider not attaching it to the networks
there. Consider all of the different software on your machine that will
be trying to connect to IP addresses inside your organization:
anti-virus updates, NetBIOS shares, etc. You would be surprised how
persistent the software loaded on your Windows laptop is nowadays and
all of this traffic is information leakage over a hostile network. At
the office or at home, this information leakage probably isn't a big
concern, but when you are attaching to a very well monitored network you
should think twice about it.



THINGS TO EXPECT:



*) The wireless network will go down... often. Despite the best efforts
of the organizers, it is very difficult to keep the wireless network
up and working.


*) There is all sorts of games that are played upon the wireless
network. Fake access points go up and down. Rogue DHCP servers
answer to requests. The routers get hammered with DoS attacks.


*) Expect weird DHCP and DNS stuff to happen.


*) Finally, try to recall all of the attacks you have seen in the last
year and dismissed because the attacker needed to be local to your
network. Then realize that you are about to connect to that network.

BEFORE YOU LEAVE:



*) Regardless of OS, make sure your laptop is patched. If running
Linux, make sure your kernel is current/patched.


*) Double check your firewall settings from another machine.


*) Setup SSHD on the proxy machine that is running on a port different
than 22. I would keep it below 1024 to ensure that a root-owned
process is running the daemon.


*) Hard-code your proxy box IP address into your hosts file on your
laptop. This prevents DNS hijacking at the conference.


*) Verify that your SSHD allows public key authentication only. If you
didn't already have it setup, generate a public/private keypair on
your laptop. Also, make a note of your server's public key on your
laptop to reduce any question of man-in-the-middle attacks
later.


*) Verify that your SSHD only allows SSH protocol version 2.


*) Setup a Squid proxy server on that box. This will allow you to proxy
HTTP and FTP traffic.


*) Configure another machine to log all attempted connections to the
destination box running your SSHD. This is just for you to review
later when you get home and see if anybody was watching you connect
to your daemon.


AT THE CONFERENCE:



*) When you get to the conference, try to hard-code the MAC address of
the default router. Use the arp command to do this. The MAC
addresses of the routers are usually published at Black Hat.


*) After booting your laptop, SSH to your proxy box and setup port
forwarding. ssh -L3128:localhost:3128 <username>@<proxy_ip>.


*) After the SSH tunnel is up, make sure that your web browser is using
the proxy address of 127.0.0.1:3128. This will force all of the web
browser traffic to transcend the SSH tunnel and get handled by the
Squid proxy server. For command-line applications on UNIX, you can
sometimes set the http_proxy and ftp_proxy environment variables to
the proxy IP address.


*) With all of this in place, I would still be very hesitant about
connecting to corporate e-mail systems (especially Outlook Web
Access). Do you really want to put your organization at risk by
connecting to these systems and having someone shoulder-surf your
email?


*) Do you believe strongly in your VPN client? That's great. But why
put your organization at risk by showing everyone else the IP address
of your VPN gateway?


*) If you are running Windows, consider the following additional
measures to prevent information leakage from NetBIOS broadcast
traffic...


*) Turn off Client for Microsoft Networks.


*) Turn off File and Printer Sharing.


*) Turn off NetBIOS over TCP/IP.


*) Consider changing the domain name and machine name of your computer.



[end]