Author: James

Recently changed my email over to Microsoft’s Office 365 which saved me about 2 thirds on what I was paying!

Migration went ok although I had to manually migrate using Outlook – export to PST from old account, import PST to new account etc.

One piece of advice they did give me was a DNS Propagation Checker that would check the propagation around the world when I changed over my DNS MX records to point to Ofifce 365.

Goto: http://www.whatsmydns.net

To check an MX record change the pull down to MX and enter your domain name e.g. contoso.com, hit search and the map and table will give a green tick or a red x depending on status – invaluable!

I needed to keep a Windows XP machine which I connected to using RDP connected all the time – until I logged off.

The default was set to log me off after 30 mins or so of inactivity which meant I had to go through the whole process of logging on again!

It appears the only way to achieve this is by editing some registry entries:

HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindows NTTerminal Services

Delete the MaxIdleTime key.

If MaxDisconnectTime key is also present then delete that as well.

Now my RDP connection stays connected as I wanted.

We had some rogue windows updates but we only had the GUID number

e.g. 10A48D13-24FD-4970-95A4-1467C90AFDBE

How to match the GUID with the KB article in order to see the details?

Use Microsoft Update Catalog:

http://catalog.update.microsoft.com

Paste in the GUID to the search form.

We started getting this message mid 2011 after upgrading to Adobe Acrobat Reader 10.

It transpires it has nothing to do with the EULA and only occurs when you try to open acrobat files with the characters ‘CR’ anywhere in the filename.

Now I know that sounds rediculous but it’s true! Test it out if you don’t believe me.

We got around this problem, whilst Adobe took their time with an update, by rolling out a group policy change to a registry entry as outlined in this excellent article, many thanks to Patrick Hoban:

http://patrickhoban.wordpress.com/2011/07/09/124/

We thought no more of it until recently after we upgraded our terminal server users reported the same error occuring – we had not bothered to factor in the registry change to new builds as we assumed it would be rectified in the near future by Adobe. It transpires they did solve it with version 10.1.1 in September 2011.

Only just got around to writing this up so many of you may already be aware of this change in IE’s behaviour.

The IE Cumulative Security Update for October 2011 introduced some major changes to the way IE stores cookies. 

See: http://support.microsoft.com/kb/2559049 

And a good article that summarises the changes is here: http://blogs.msdn.com/b/ieinternals/archive/2011/08/12/internet-explorer-9.0.2-update-changes-file-protocol-and-cookie-naming.aspx 

This update affected all versions of IE from 6 to 10.

It used to be that Internet Explorer cookies were stored in the users cookies folder (c:usersusernamecookies or c:documents and settingsusernamecookies) in the form: username@domainname e.g. admin@bbc.co[1].txt 

After applying the update cookies are now stored in a random letter and number format e.g. F6F3N6DQ.txt 

There is no way of telling which cookie is which without opening each text file and inspecting the contents – and even then it’s not obvious. 

Also, there now appears to be a new entry type in the temporary internet files cache folder e.g. ‘cookie: admin@bbc.co.uk/’

This is linked in some way to the relevant file in the cookies folder. For instance if you delete ‘cookie: admin@bbc.co.uk‘ from temporary internet files folder it deletes F6F3N6DQ.txt in the cookies folder. It seems that the specific user and domain information for the cookie is now being stored in the temporary cache rather than the filename.

Therefore, the entire way IE stores cookies has been changed.

The reason given is for security purposes i.e. it is more difficult to find and manipulate a users cookies. This seems absurd as the cookie can still be located via the temporary internet files. However, how you would do that programatically is a problem. As always, a change in security will break things and this change will break any application that relied on matching cookies in a file manager context. In the same way that it is more difficult for malicious software to access the cookies so it is more difficult for trusted programmes to access cookies.

It transpired that the recommended way of handling cookies in an IE application/add on is via the internal cache using the WININET Class. See IE Architecture: http://en.wikipedia.org/wiki/Internet_Explorer

This is pretty complex programming (see below) – so Microsoft have made something which was easy 100 times more difficult. Nothing new there – obfuscate, obfuscate, obfuscate should be Microsoft’s motto, that’s how it makes it’s money after all!

The WinInet class declaration that we use for an IE addon is available here: WININET_CLASS.TXT

You then have to use the 

Wininet_Class.FindFirstUrlCacheEntry

Wininet_Class.FindNextUrlCacheEntry

To loop through the cache entries – you can then use the GET and DELETE functions to actually achieve anything. Throughout all this you have to use memory handles to cycle through the cache buffer.

A sample implementation can be provided on request.

We had a problem resolving URLs and began using the NSLOOKUP command to debug the problem.

NSLOOKUP looks up the IP address of an URL using the DNS servers assigned to your network card.

This was in a Windows Active Directory environment so NSLOOKUP will send your request to the local DNS server – usually that serve,r if it cannot resolve the address, will go to the internet and get the address from your ISPs DNS server or specific DNS servers that you have allocated on your primary internet connection.

For example:

NSLOOKUP www.bbc.co.uk

Should return the IP address of the BBC web server, usually: 212.58.244.71

But it was returning instead:

Non-authoritative answer:
Name:    www.bbc.co.uk.CO.UK
Address:  67.215.65.132

The IP address returned is our external DNS provider’s default web page when it cannot resolve an IP address (in our case OpenDNS).

With the NSLOOKUP debug commands you can look more closely at the DNS conversation:

NSLOOKUP -d2 www.bbc.co.uk

This command will return a plethora of information but if you look closely it begins to make sense. In this case the address was attempted to be resolved on our local DNS servers and then when it couldn’t resolve it passed the query onto the external OpenDNS servers but, before it did this, it added the .CO.UK suffix.

This occurs because the local DNS server firstly adds the local domain so that it looks up e.g.: www.bbc.co.uk.adroot.yourdomain.co.uk

This does not resolve so it then drops the first part of your domain and tries again e.g.: www.bbc.co.uk.yourdomain.co.uk

This does not resolve so it then tries to drop the last part of your domain e.g.: www.bbc.co.uk.co.uk

Because this address is now outside your domain it sends the request off to the internet e.g. OpenDNS servers. Of course these DNS servers cannot resolve the address so it drops it and pushes back a fail or their default web page.

This is all by design. To resolve the address you need to remember to add a dot to the end of your request:

NSLOOKUP www.bbc.co.uk.

The dot tells the local DNS server not to attempt to resolve by adding the local domain – it immediately just tries to resolve www.bbc.co.uk and because it is not in your domain it sends the request to your internet DNS which resolves it successfully.

Use: NSLOOKUP -d2 www.bbc.co.uk. and you will see the difference.

Recently caught the XP Home Security 2012 virus (strictly speaking ‘Malware’) on one of our XP machines.

Found this solution to work without any problems: http://www.bleepingcomputer.com/virus-removal/remove-xp-home-security-2012

I’m impressed that MalWareBytes seems to be the best at detecting and getting rid of this Malware – so much so I bought a copy to run on my personal machine.

The MalWareBytes scan found the following which seemed to be related to the Home Security malware:

Registry Keys Detected: 1
HKCUSOFTWAREMicrosoftWindowsCurrentVersionExtStats{B64F4A7C-97C9-11DA-8BDE-F66BAD1E3F3A} (Rogue.WinAntiVirus) -> Quarantined and deleted successfully.

Files Detected: 3
C:Program FilesEA GAMESMOHAAEreg MOHAABgo_ez.exe (Trojan.FakeAlert) -> Quarantined and deleted successfully.
C:Documents and SettingsJamesLocal SettingsApplication Dataqkm.exe (Trojan.ExeShell.Gen) -> Quarantined and deleted successfully.
C:Documents and SettingsJamesLocal SettingsTempcnrxsomawe.exe (Trojan.FakeMS) -> Quarantined and deleted successfully.

The first file detected intrigued me – this is an old FPS game: Medal of Honour Allied Assault, which I had fired up a few weeks earlier and played some online battles. I assume that was the attack vector – old game, probably with loads of vulnerabilities connecting to a dodgy game server. The attack then kicked in at the next MS security updates patch Tuesday.

After cleaning and re-booting I found I was still getting the message saying Automatic Windows Updates were switched off in the taskbar even though under System, Automatic Updates they are switched on. Re-registering Windows Updates using these commands solved that problem:

Click Start, select Run and type:

regsvr32 wuapi.dll
regsvr32 wuaueng.dll
regsvr32 atl.dll
regsvr32 wucltui.dll
regsvr32 wups.dll

Press [Enter] after each one and wait for the success message

Many thanks to the guys and gals at bleepingcomputer.com