The Bit Bucket

Tuesday, July 31, 2007

Security Industry Commentary

Last night I watched the "Diana: Last Days of a Princess" documentary. I admit that I largely watched it just to moan about how much the British media is still concentrating on Diana but I was pleasantly surprised at how good the documentary was because they largely focused on the two bodyguards assigned to Diana and Dodi.

What really surprised me was the similarity between physical security and computer security. Both have a recommend set of practices or standard operating procedures. During the final days of Diana's life the documentary highlighted that the two bodyguards were physically exhausted and their recommendations for security practices had been ignored with the result of Diana and Dodi paying with their lives.

Now computer security isn't as hands on as computer security but there are startling similarities with the way people in both industries are treated. I still don't understand why we as security and IT professionals are hired and often ignored/overruled by management.
Obviously, there are some occasions when management have to do this to fit in with a company vision or similar which has not been fully cascaded to the business or for reasons of corporate confidentiality have to be kept quiet but this sort of practice happens all to often.

Labels: ,

Thursday, July 26, 2007

Careful when testing security

I was amused to read that two Daily Mirror journalists where arrested when 'testing' security procedures on London Underground. Whilst it they say that they have a 'journalistic right' to expose security holes I personally think that it's just another type irresponsible disclosure where the people concerned don't have a chance to put right the problem before it's widely reported.

On another completly different note I was browsing You tube earlier today and found this fantastic clip of Bill Bailey and his rendition of the BBC News theme tune. I had the fortune to see Bill Bailey live once and the guy is a genuis.

Labels: ,

Careful when testing security

I was amused to read that two Daily Mirror journalists where arrested when 'testing' security procedures on London Underground. Whilst it they say that they have a 'journalistic right' to expose security holes I personally think that it's just another type irresponsible disclosure where the people concerned don't have a chance to put right the problem before it's widely reported.

On another completly different note I was browsing You tube earlier today and found this fantastic clip of Bill Bailey and his rendition of the BBC News theme tune. I had the fortune to see Bill Bailey live once and the guy is a genuis.

Labels: ,

Tuesday, July 24, 2007

Is it time to scrap the password?

As password protection gets more secure the actual passwords for users get weaker.

A paradox? Not so, let me explain.

A few years back the biggest problem was a password going 'over the wire' and being intercepted. This can easily been seen in telnet. Just capture a telnet session and you will see the password in plain text contained in the packet capture.

Obviously this is not very secure so the next step is to encrypt the password on the workstation and send the encrypted password to the server. This way the plain text version never left the workstation.
This was defeated in fairly short order because the level of encryption used was not very high.

The next step was to use encryption and a salt but this was also broken is short order thanks to the salt being included with the hash.

Currently, Kerberos does a wonderful job of making sure a password is secure. Not only is it encrypted on the client machine with a one-time hash but it never leaves the machine - only bits do - A bit like a bank asking you for five letters from your address at random locations to very its you. Kerberos also defeats a replay attack by encoding the time into the response. If the domain controller sees a client-side request with the same or an earlier time its rejected as a reply attack - this is why its vital to make sure your servers and clients all have the correct time.


So, how does this make our password weaker?

In many systems its possible to check the password complexity levels but it's getting harder to check to see if users are following a pattern, e.g. password1234, password1235, password1236 and so on because the password is NOT stored on the server and it's not possible to decrypt the hash the checking must be done on the client side machine - BUT, if the client side machine stores the password it will have weaker security than the domain controller and as it's easier to access a client side PC than a locked away domain controller the passwords should be stored on the domain controller.
BUT if the passwords are stored on the domain controller they must be decryptable or plain text otherwise certain complexity checks cannot be enforced.
This would again open up the password to packet sniffing attacks.

It seems that the password has run it's course but it's there something out there that's easy to use, doesn't require a heavy infrastructure (like RSA tokens) and offers two-factor authentication?

Labels: ,

Tuesday, July 17, 2007

Increase in eCard scams

A few weeks ago I got a fairly genuine looking ecard email but something about it triggered my suspicious so I did some further checking of the mail message and spotted that the from address didn't match the listed name and that the link for the ecard was an IP address rather than a website.
The link itself displays a message "If this card does not download in 15 seconds click this link" and the link takes you to an .exe file so obviously not a legitimate site!

This was about two weeks ago, since then the number of emails I'm getting with this type of exploit has been steadily increasing so it appears that there is a trend increase for this type of attack and it does make sense. This type of attack is less likely to be stopped by mail filtering, will not trigger an IPS alert and probably won't be stopped by local anti-virus software - Hopefully the .exe file that the site points to will be stopped by local AV.

I've downloaded the .exe but not had a chance to see what it does. I will be analysing it in more detail later on today and will blog back here in the meantime keep a watch out for dodgy ecard emails.

Labels:

Tuesday, July 10, 2007

Reporting new spyware

When setting up the network at the new house I fired up each machine to test out connectivity and other behaviour before putting it back on the network. One of the laptops was behaving a bit oddly so I put it to one side for further examination and carried on with the rest. The area where the computers are located is a real pain though as there is only one power point - Something that will need to be fixed as I need about 30 power points for the kit!

Looking at the laptop I went through some standard checks to see what was running at startup and so on, Nothing unusual popped out so I looked deeper into the services and once service I tried to disable gave me error so I had a look in the registry to find it calls itself tixqvawf in the registry and goes by a host of different names when you delete it.

I dug further and found that it launches a DLL called bkldbkl.dll which I sent off to Sophos and McAfee for analysis - Now this is where it get's interesting.
Sophos replied within 48 hours to say that it was spyware and that they would be issuing an IDE update would to cover it and the link is here.

McAfee sent back an automated reply to say that an AVERT researcher would be looking into it because the automated test could not find a match. Further down it said that automated testing would only occur if the original sample was in a password protected zip and that a researcher would only look into it if that was the case but the one I sent wasn't.
So now I've got two pieces of conflicting information.

I assume that because McAfee have not bothered to get back to me they require a password protected zip file but it's annoying that the sample wasn't rejected because it wasn't password protected. All a bit silly really and McAfee will miss out because of the poor wording when reporting new items.

Labels: