MSN and MS-Agent exploits

There are two rated high vulnerabilities exist in Microsoft software that's publicly disclosed and have the patches released!

One of them affecting Windows OS is explained in http://www.microsoft.com/technet/security/bulletin/ms07-051.mspx for MS Agent vulnerability which pretty much affects those using Windows 2000 with SP4 (most likely a lot of W2K users). This attack requires access to a vulnerable (or malicious) website which you choose to access. Mitigation factors include disabling MSAgent or otherwise, more effectively, do not get too "friendly" on the WWW and get that patch.

MSN Messenger (and Windows Live Messenger) is also vulnerable to an exploit by crafting a malicious code inside the the request to ACCEPT AN INVITATION FOR VIDEO CHAT. I regard this as quite dangerous as this particular type of vulnerability can easily be scripted and thus spawn the network for vulnerable sources. MS KB article here explains it all http://www.microsoft.com/technet/security/Bulletin/MS07-054.mspx. This particular attack however does require a user interaction where an "accept" response is required for the exploitation to successfully take place. Also, when compromised, if you turn on UAC in Vista, most likely the action to allow administrative rights will be triggered by UAC. This is when you say no if all else fails up this point.

Does this affect you? Most likely if you use Windows 2000 or Windows Live Messenger or both.

How bad is it? Remote exploitation is possible and can run in the context of a currently logged on user.



Both problems have been reported responsibly and Microsoft has publicly released related patches. Please update your software.

Outlook Tip: Retrieving "lost" attachments

When you directly open up attachments in Outlook, they launch the application that corresponds to that attachment, e.g. a .xls file will launch Microsoft Excel. So when you start working on this file, remember to save it somewhere else (save as) to where all your other files are stored. When you click save, it will save the file in Outlook's temporary attachment cache folder.

Just say you've saved a file (File->Safe) and closed Excel, then later cant find the file anymore!!! you start to get all Tasmanian devil about it..ITS NOT even in the Excel's recently opened document list. Well DON'T PANIC YET...

Most attachments launched directly from Outlook will be stored in a cache (temp) folder before getting executed within the corresponding application. This folder is normally in C:\Documents and Settings\username\Local Settings\Temporary Internet Files\OLKxxx (where username is your logon username) . This is where all temporary files are stored directly from outlook. Some may have different settings to this and you can easily find this path out inside your registry Key HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Security and look for the key OutlookSecureTempFolder...

Now access the file/folder directly using run or explorer (note in most OS-es, this particular folder and preceeding folders could be hidden, so unhide it from Explorer's folder options first).

This is also a great place to find out what you girlfriend's been receiving in her email... :P

Split-brain DNS

Many a times you might cross organizations that implement internal DNS for name resolution. This is especially true for those running Microsoft Active Directory, where DNS plays an integral part in it's directory services lookup. Problems can happen when especially the domain names for both internal and external happen to be the same or to achieve seamless name resolution, an internal DNS need to exist to match that of external names.

Lets take for instance an email client that connects to their email infrastructure using the name email.company.com. In this case, when a user goes out of the organization, he or she can receive emails since the name email.company.com resolves to a valid external IP. Now, this user comes back into company and the company implements Active Directory but when resolving email.company.com either;

a. Does not get resolved as you may have a similar zone setup
b. Resolves to an external IP (whereas the server is actually internal)

Both these problems mean, the user may not be able to receive emails no more.

This is where administrators can setup a split-brain DNS. A split-brain dns in simplest possible explanation is having similar DNS zones internally and externally. Records like A, CN, SVR can be different as long as it meets your requirement for security, performance and accessibilities.

For instance, taking the exact example above, say Ahmad receives emails externally by using the email.company.com (which resolves to 202.188.0.133) then he comes back to his office, the exact same name email.company.com now resolves to 10.1.1.1 which is their email server but accessed internally now. This is because his administrator has setup a split-brain dns to ensure internal users do not resolve internally servers as external IPs and work the gateway for no apparent benefit.

There's a little bit of administration involved to ensure records match that of the internet. You must create records that correspond to the split brain domain to match the resources or records that exist externally if this record or server does not exist internally. For instance, the company in our example, hosts their external DNS to an ISP. This ISP also hosts their website www.company.com. This record should also exist in your network, simply because you assume the ownership of the zone company.com in your split-brain dns setup. Otherwise, users will not be able to access this www.company.com internally if you do not have such record. This record however will contain a live IP address matching that of the ISP. Remember, if the record does not exist, it will fail and will not forward to a root or top level DNS since you assume the role of the authority of this domain company.com.

There's a downside to this amongst others, is that is it can be subject to abuse and thus lead to a phishing or pharming attack. Imagine, internally you could setup the zone maybank2u.com and host your own www.maybank2u.com to resolve to your own little fake maybank2u website ;)...fun eh.

ISA Server 2006 VS Exchange Outlook Web Access

A customer from Cambodia (shout out to Whaddanak of CBL) once asked ways in which one can publish a front end Exchange server securely in a DMZ (DeMilitarized Zone). The obvious answer is DEFINITELY YES. Since Exchange 5.5, OWA could easily be isolated from the internal network thus lowering the risk of a security compromise on valuable data such as mailboxes.

Publishing a Front End server in Exchange 2000, 2003 and 2007 today is a little like taking an Exchange box and stripping it down to "enough" features for; all required Exchange services to work and of course, the Web components and dependencies such as IIS. While this is a great way to start working towards security but it still introduces concerns to administrators for possible administrative and certain security issues for example, Active Directory membership (since the Exchange server needs to be part of the domain) ports need to published between DMZ to Internal DCs, securing the Windows server in which Exchange server reside (since it's being placed in a DMZ) and configuring firewalls to allow communication between internal mailbox servers (which can be rather complex since you need to codehack ports in which the information store listens on etc). Other concerns could also be the inability to implement multiform factor authentication (which is not possible with just Exchange FE-s). Here's a good (detailed) sample article one can use to do just Exchange FE publication on DMZs or alike http://www.msexchange.org/tutorials/OWA_Exchange_Server_2003.html

Fortunately, there's a much easier, secure and "cheaper" way. Yes, you guessed it, USE ISA SERVER 2006. Cheaper? (i leave this to you to do the math here).

Lets continue this topic by simply looking at key differences which an organization can directly benefit by using ISA Server as their FE for Exchange OWA. Here, i present, my oh-so-familiar way of presenting benefits:

ISA Server's top 10+1 reasons as an Exchange OWA Front End

1. Its a firewall - Once installed, it's a dead Windows box which only do stuff you allow it to do. You do not need to crack your head open on how to block ports and secure this secure that. Of course, you still need the basic hardening guides to help enhance the ISA box..la.
   
2. It can publish one or more Exchange OWA or backend servers with OWA enabled and do a better load balancing job (like application response-e.g. http/s-get) than WNLB (network level only)
   
3. You can do all the HTTP filtering you would normally do with an ISA server like URL filters like HTTP signatures filtering, headers, extensions, methods, HTTP redirection to HTTPS (which you would normally use a ASP script in OWA 2K3 or lower) setup concurrent connections and connection limits (anti DoS), etc...
4. Perform higher degree of control by using Forms based authentication via ISA server like the use of persistent cookies, HTML customization and password management.
5. Single Sign On - Yes, once you sign on to OWA, you could also be signed on to say your intranet web servers!
   
6. You can filter out users at the ISA server level itself and lockdown on users whom are not suppose to use OWA or enforce limits on time for instance. You can also specify sources like directory based users groups, IP addresses, domain names, etc.
   
7. You can choose to bridge SSL! That hundreds of thousands of dollars application filtering IPS can finally see what's going on with OWA on SSL
   
8. It can support multiform authentication - Yes, multifactor auth is possible meaning you could have your OWA users sign on to a certificate and/or an RSA token or a combination.
   
9. Setting it up is a breeze, you do not need to introduce an additional Exchange server in your organization (or the Exchange SM ). All done through wizards and its up and running when you click APPLY!
   
10. It can cache!, compress, you can do other fun stuff like taking the OWA offline by sending users to a "...this page is unavailable page.." for maintenance and you do it all from ISA rules!
11. BONUS POINT: You could also perform attachment rules, customized logoff pages etc straight from the ISA server rule line itself.
    

So there you have it, again, a top 10 type reasons why you MUST insist on ISA Server 2006 as a front end Exchange OWA (and also your corporate firewall :) ) when using Exchange 2K and up.

Happy ISAlating your Exchange