Part two nearly here.....

With a bit of my OWASP work complete I thought I would put part two of this post up. I decided to video the whole thing, it was my first time and I have had nothing but trouble with it. The video was nearly 100mb so it took ages to upload and when it finally did the quality was terrible, it looked great locally.

I will just post up screenshots tomorrow like I did for the first bit of the post. I will sort this out tomorrow night, so only one more day to wait. If I get the video uploaded and looking good I will add that in.

If I had more time I'd get it sorted properly but I fly out to the British Grand Prix on Thursday morning and I'd like to get it posted before I depart.

Dave

Bypass modern anti virus with an 8 year old backdoor

This is the first of a 3 part blog entry, well blog entry/warning/tutorial - pick which you think fits this best. As soon as people find out I work in IT Security normally the first question I'm asked is which is the best Anti Virus product to use? Normally I just say one of the big providers, F-Secure, Symantec etc but I do also state that they aren't a silver bullet.

What I'm going to do in this 3 part blog is first download tini.exe which is a backdoor roughly 8 years old and submit it to Virus Total. This will be scanned by 33 different anti virus products and I will show the results. Then the fun bit, I will modify just the port that tini.exe listens on and its name then see how many report it as a backdoor!

Secondly I will show you how to wrap this backdoor into any application you want and have it install silently along with the real application. The third step will be a demonstration of a second machine connecting to this backdoor.

First download the tini installer. I will submit the default Tini.exe backdoor to virus total and see how many of the modern anti virus companies will detect this old backdoor.



All of the products have figured out that it is some kind of backdoor/trojan.

So now to crack tini open with a hex editor and find the default port value, 7777 in this case:


Now I have picked a random port of 39846 (9ba6) and I will edit the backdoor as shown below:


I saved the modified version as dave.exe and I will re-submit this Virus Total. The results are shown below:



You can see that only 21 of the products now reported this file as being malicious. So by just changing the listening port and the name of the backdoor 21/33 products detected this 8 year old backdoor (first scan was 32/33). It is hardly inspiring reading is it?

Part two of this post will show you how to wrap this modified backdoor with a genuine application to install it in stealth on the victims machine.

Please be patient for post two, I have commitments to meet for the OWASP Code Review guide for the next few days before I can put part two up.

Interview with the developers of Backtrack

I have been listening to episode 112 of the PaulDotCom podcast (PaulDotCom) and it contains a fantastic interview with the guys behind the BackTrack distribution.

I highly recommend this podcast to existing and new BackTrack users alike.

The guys talk about where the distribution came from, some of the problems they have faced, some of the tools in the latest version and plans for the future.

The BackTrack distribution can be found here: BackTrack

Dave

Virgin Media data breach

What is it with 2008 and companies losing data on CD's?

The latest company to lose data this way is Virgin Media, they have lost a CD which was un-encrypted and contained the bank account details, names and addresses of 3000 customers.

More information can be found here: Virgin Media data loss

What more can I say, its Friday night - maybe I will come back and add a rant to this post tomorrow :-)

Dave

Secure Development - preventing Cross Site Scripting

Hi everyone, I have included a Google Docs reader below for a paper I have written on Cross Site Scripting. The paper discusses the three types of Cross Site Scripting attacks as well as code examples and the associated fix.

The paper can be viewed here:

Preventing Cross Site Scripting

The formatting has been messed up a bit by Google Docs but I hope it makes sense to everyone.

PCI 6.6 mandatory compliance date looming

When I first read PCI DSS v1.1 requirement 6.6 caught my eye for two reasons. I could see the potential security benefits but also the extra work I would have to do!

Requirement 6.6 is shown below:

Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:

• Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
• Installing an application layer firewall in front of web-facing applications.

Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement.

Wow, all custom code externally reviewed - time to save up the pennies to pay for that! A lot of the community were scratching their heads trying to figure out whether this actually means having every line of custom code reviewed, even for a relatively small company we were a bit worried about the cost. Fortunately the PCI Council released a clarification document earlier this year detailing that a company could meet 6.6 by one of the following approaches:

"The application code review option does not necessarily require a manual review of source code.

Keeping in mind that the objective of Requirement 6.6 is to prevent exploitation of common vulnerabilities (such as those listed in Requirement 6.5), several possible solutions may be considered.

They are dynamic and pro-active, requiring the specific initiation of a manual or automated process. Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats:

1. Manual review of application source code
2. Proper use of automated application source code analyzer (scanning) tools
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools"

We felt that our current approach towards secure application development and code reviews met the intent of the first option in requirement 6.6. We have had an external company who are specialist in auditing and application security to review (and produce a report on) our process.

I would love to know what kind of approach others have taken to satisfy requirement 6.6.

Remember folks, it becomes mandatory in 15 days so act fast!

Even more documents lost....

Following on from my post last week which discussed the loss of Top Secret government documents a second breach has been hitting the headlines.

I was amazed that these kind of documents were left on a train once but to happen twice is beyond belief. Several of the statements made by government officials/in news reports did grab my attention, firstly:

"His work reportedly involves writing and contributing to intelligence and security assessments, and he has the authority to take secret documents out of the Cabinet Office - so long as strict procedures are observed."

So the government actually allows Top Secret (National Security documents) to be printed and taken off its premises. As a Security professional my first reaction was one of surprise until you consider the major security blunders by the UK government in the past 12 months.

Secondly, a comment made by Keith Vaz, Chairman of the Home Affairs Select Committee:

"no official no matter how senior, should be allowed to take classified or confidential documents outside their offices for whatever reason."

That seems a good enough start in my opinion. But this really does come back to very last point I made in my original post last week about printed data.

It is one of my biggest professional fears, how do I know people aren't printing sensitive data off and stuffing it into their pockets? As a financial services company we get emails every week from individuals and banks (yes, banks) which contain un-encrypted sensitive data. Fortunately we have well defined procedures and skilled staff to respond correctly to these emails. But what if we didn't?

In terms of technical controls we can control the risk of theft around this data but if it were printed then all bets are off. A user could just print the email, if we prevent printing then could do a screen print, they could even write it down and away they go. In this day and age of mobile phones with high resolution cameras what is to stop people just taking a picture of the data and taking it that way?

When you think of it like this you may feel a bit of sympathy for the government, but they have the budgets and the ability to hire the top talent to prevent these breaches.

Security, is it really that hard?

I read and hear about security breaches almost everyday and I always ask myself the same question, "is security really that hard?".

Today I have read two articles on the BBC website, one (BBC Article 1) is even more credit card numbers lost and the second (BBC Article 2) is more UK government confidential documents lost.

Cotton Traders have lost 38,000 credit card numbers through their website. No technical details of the breach have been given but its likely to be a SQL Injection attack. The article on the BBC doesn't give much information away. What it does give away is false information about the TK Maxx data breach in 2007. The article falsely stated the TK Maxx breach occured through their website.

TK Maxx (more precisely TJX) didn't loose their card numbers through their website. The breach occurred because of someone noticing that the TK Maxx stores used WEP to protect their internal POS networks. Through war driving they cracked the WEP (not a highly technical hack) and went onto take close to 100 million card numbers over 18 months. For such a big news company I would have expected a more accurate report from the BBC.

Back to the original point, the Cotton Traders breach. Many sites are vulnerable to (again this is based on my assumption) SQL Injection so only half a scowl for them on that. But cleartext card data, thats not really forgivable. If I were investigating the breach my two main questions would be 1) Did you need to store that data and 2) Why didn't you securely store it (i.e. encryption)? I'm sure we will never publicly know these answers.

My last point on Cotton Traders is the breach occurred in January, 6 months ago. The sooner we see more laws like California's SB 1386 the better! The public should be made aware sooner of such breaches, just think how many are probably going un-reported.

The second article focuses on the fact that the UK government has lost more information. This time a government official has left printed copies of Top Secret documents on Al Qaeda and the war in Iraq on a train. A police investigation is being conducted and I'd suggest that some poor employee that may not have known better will be receiving their P45 soon. I could write all night about the potential problems that have occurred to cause this loss of data but I won't!

At a recent Data Privacy seminar we were all unanimous in our fear of printed data. We can have all the latest and greatest firewalls, IPS/IDS, encryption etc but once its on paper what can you do?

Dave

How safe is hackersafe?

A lot of websites now have the hackersafe logo displayed on their website. I've always wondered what this actually means for a website, what do they check etc.....

Well today I got a phishing email, I followed the link to see who had been exploited this time. The phishing site was being hosted a few directories deep on the webserver so I backed up to the homepage (away from the Phishing site to the "real" site) to be greeted by the lovely hackersafe logo. The hackersafe logo proudly proclaimed that the site was hackersafe, certified today!

Obviously the site isn't hackersafe. So what does this mean, is this a security company providing an inferior service spreading FUD and providing no real security? My opinion would be maybe, potentially there is a need for this kind of service but in my opinion hackersafe does not provide what its clients believe it does.

It is worth noting that in October 2007 McAfee payed $51M (potentially rising to $75M) for hackersafe. The service being provided and those figures remind me of one thing, "This time next year, we'll be millionaires!" (Delboy, Only Fools and Horses).

My public security talks

This year has been good for me so far for public talking. I have been lucky enough to be invited to speak at the Irish Web Technology Conference (IWTC 2008) and an OWASP Ireland Chapter Meeting.

I had a lot of fun doing these talks, IWTC was based in the Cineworld cinema in Dublin. It was a very strange feeling to actually be presenting my work on the big cinema screen where only weeks earlier I was watching Shrek!

The IWTC talk was focused on a high level discussion of the current threats application developers need to protect against in 2008. I also discussed how to write code to protect against these threats. I finished off the talk with an explanation of the application security processes I have implemented at Realex Payments.

The talk can be viewed here (Google Docs has broke some of it, contact me for the original):



In April Eoin Keary (OWASP Ireland Chapter Lead) invited me to talk about Application Security and the PCI DSS. The talk focused on how PCI DSS would affect an application developer along with an overall opinion on PCI DSS and how it applies to application security. I presented this talk at Ernst and Young in Dublin.

The talk can be viewed here:



All feedback, good or bad, is welcome!

My first blog!

After reading so much about blogging I thought it was about time I started!

I was inspired to start my blog after my friend Martin mentioned me on his blog (http://brigomp.blogspot.com/). As the blog is in Spanish all I understood was my own name, fortunately it was all good.