Brilliant Thinking

Peer to peer (P2P) computing is a technology which allows programs installed on individual PCs to communicate with each other without the need for a central [web] server. There are numerous collaboration tools around that operate on P2P principles, and there are also numerous file sharing tools which work on the same basis (e.g. Limewire), and the earliest example of a P2P system was Usenet.

However, as with all technologies, there is a darker side. And the dark side of P2P is the botnet. Botnets are groups of PCs which are infected with malware programs designed to steal information or to relay spam. The programs are covertly installed onto the target PC as a result of the users’ normal surfing or email behaviour (just like getting a regular virus), but because the program operates as a P2P node, it can leverage the power of an entire network of other versions of the program installed on many, many other PCs.

Consequently, botnets have emerged as one of the leading threats to corporate and personal computers. More so that a traditional virus, trojan or other spyware.

Once installed [inside a network or on a PC], these malicious bots can launch phishing or denial-of-service attacks, relay spam that appears to come from the infected machine’s network, or install software that can log keystrokes. Bots go one stage further and receive instructions from control nodes - this is different to the usual “all nodes are equal” in a conventional P2P network. By maintaining a two-way communication with the botnet, hackers can update their activities. For instance, infected machines on a botnet that distributes stock-related spam could easily be repurposed to launch phishing attacks at the push of a button.

“Botnets have become more sophisticated,” says Avi Chesla, vice president of security for software provider Radware. “Some are using encrypted channels [to communicate], and they can be controlled through [Web] traffic, which makes it harder to detect and prevent the activities of these bots.”

“A botnet of 400 [infected machines] is worth more than twice as much as a network of 200,” says Sam Curry, vice president of threat product management for network management software provider CA. “Botnets increase the risk to the community because when you’re dealing with 10,000 of these acting in concert, they can bring parts of the Internet grinding to its knees.”

The largest known botnet operating today is the StormWorm botnet, named because malware was first distributed through viral e-mail that promised photos of damage from European ice storms earlier this year. However, the payload contained the bot which was installed on the visitor’s PC.

Collectively, StormWorm machines offer more computing power than the largest supercomputers. Security firm MessageLabs estimates the StormWorm botnet controls at least 1.8 million computers to relay spam and distribute malicious code. In late August, StormWorm-infected PCs sent an estimated 57 million malicious e-mails in 24 hours, according to Postini, a security provider.

Security researchers say botnets are more insidious than traditional virus or worm attacks because they’re designed to remain hidden, and can compromise a PC or a network without users noticing that their devices have been infected.

Bots first appeared on the security landscape a few years ago in denial-of-service attacks. When several thousand infected machines received a remote command, they sent repeated information requests to a targeted server in an effort to overwhelm the server and knock it or a Web site offline.

Because botnets are designed to resemble legitimate Internet traffic, blocking them focuses on either preventing delivery of the bots or from letting infected computers receive instructions from the botnet controller.

“Bots used to violate protocols by sending too many request per second, but now their behaviour appears completely legitimate,” says Radware’s Chesla. “Until about two years ago, bots could only create packet floods or scan a network. Now the bots generate [legitimate-appearing] requests to a server.”

Botnets are the latest manifestation of hacking’s increasing professionalism. Once the goal of hackers was simply bragging rights, but now malware developers are stealing financial information or relaying spam. Professional hackers, often financed by organized crime syndicates, are interested in avoiding discovery and controlling infected machines for as long as possible.

“Malware developers have become very talented, they have a lot of tools at their disposal and they’re doing it for profit,” says Roddy. “They’re not doing Internet-wide virus attacks any more, now they’re targeting attacks to steal information.”

To avoid discovery, bots may try to prevent the machine they’ve infected from being attacked by other malware. For instance, one bot may try to disable others to prevent both from competing over a PC’s system resources. The StormWorm botnet has also apparently attacked Web sites belonging to anti-malware or anti-spam researchers.

In other instances, hackers combine malicious payloads and install each other’s bots on infected machines.

“The bad guys make a lot of money in doing this, and they’re motivated to find new ways to make money,” says CA’s Curry. “These guys collaborate, and we might see three or four outfits deciding to work together and leverage each other’s install base. They realize that if you have 100 victims and I’ve got 100 victims, we might as well combine them and work together.”

For larger organisations, effective firewalls and security systems are essential to monitor and statistically analyse network traffic. This heuristic approach allows such tools to detect a potential threat, alert sysadmins and suspend traffic from potentially rogue bot nodes.

For small companies individuals, the same tools are essential - firewalls and security software - to help combat the threat of the botnet. Other tools such as anti-spyware systems are also essential and frequent scans helps you keep your network free of potential threats.

However, first and foremost, the best defence is vigilance. Don’t click on links which may be suspect (especially in emails), and don’t open emails which you don’t trust. With an increased awareness of what causes infection, we can help prevent it and reduce the reliance on security software to clean up the mess our lazy behaviour creates!

Story: KPMG Digital Insider Focus

In October 2006, the spam levels jumped a massive 10% in the UK (up from an average of 51.4% of emails being spam in September to 61.4% being spam) according to MessageLabs (the world’s leading provider of messaging security and management services to business). Globally the average went up by 8.5% in October 2006 to 72.9% of email received being spam.

Source: Message Labs, October 2006

This was, in part, due to it being the start of the spam season in the run up to Christmas - ie more junk gets sent to catch unsuspecting shoppers. However, aside from seasonal variations, there are other two other key factors at play in the increase in spam.

• A trojan horse called Warezov which, once installed on a person’s PC, sends out spam continuously. The trojan horse has been spread to hundreds of thousands of computers.
• A trojan horse nicknamed SpamThru which harvests email addresses and uses them to generate spam content which gets sent out. Again, this has been downloaded onto huge numbers of computers.

It’s not clear at this stage if there is a link between them - ie SpamThru harvests email addresses and pushes content through to Warezov - but the fact is that these 2 trojans have contributed to the majority of the increased volume of spam over the last few months and the trend is unlikely to change.

A clever trick employed by SpamThru is that it contains a hacked copy of Kaspersky Anti-Virus which actually does clean up the computer and remove spam bots, viruses, etc. However, it’s been hacked to allow SpamThru to remain undetected and unchallenged by other spam bots on that computer. Consequently, people may also unwittingly install SpamThru because they think they are getting a free virus program, but they are being duped into installing a spam system.

The messages are clear:

• Spam is not going away, and will get worse
• Only ever download software you know the pedigree of
• Find a good spam filtering system

In more detail: Warezov

The first is the aggressive level of activity around one particular trojan dropper called Warezov. Tens of thousands of copies of different variants of the trojan are sent out in multiple batches, where each batch is subtly different from the previous one. Even a few bytes changed in the code will allow the trojan to pass undetected through traditional anti-virus protection. Because it is a “dropper” (a piece of code that later downloads new code/viruses/worms/malware/email content/etc onto the affected computer) it is uncertain as to what the trojan is being used for, however it seems clear that there is a connection with the huge rise in spam levels around the world. In fact, in 24 hours on 26th October, MessageLabs software trapped over 900,000 copies of Warezov. It’s been around since August 2006 and is being updated all the time to avoid detection and so continue to spread spam.

In more detail: SpamThru

The second driver of increased spam is another trojan, dubbed “SpamThru” which is responsible for a great deal of the botnet activity behind increased levels of spam. Analysis of SpamThru shows that the SpamThru makers are releasing new strains at regular intervals in order to confound traditional anti-virus signature detection. Using the “spam cannon” technique, SpamThru uses a template for each spam it sends and by combining it with a list of email addresses, each zombie (computer) is then able to pump out millions of spam emails.

Although designed to turn the infected computer into a spam-sending zombie, SpamThru employs an interesting device to circumvent the closure of the command-and-control channel. In a normal botnet, there is a central “controlling” program (called the mother-ship) which coordinates and keeps everything running. If this mother-ship is disrupted or disconnected, the entire botnet is disrupted or disabled. However, SpamThru has a “self-healing” capability in that if the mother-ship goes offline, as long as the botnet controller can access any other zombie macine, they can change it to assume the role of the new mother-ship and so maintain the continuity of the whole botnet. In other words, SpamThru is much more resilient to attacks on the mother-ship and less likely to be stopped.

SpamThru also attempts to neutralize anti-virus software by corrupting the local “hosts” file, inserting dummy addresses to override genuine anti-virus update URLs. SpamThru also downloads an illegal copy of Kaspersky Anti-Virus onto the infected computer, scanning the PC for viruses, whilst ensuring that it bypasses its own components. Interestingly, any other malware found on the system is removed the next time Windows reboots.

Back in August 2005 I wrote a piece on the relative security of Linux versus Windows (ie open source versus proprietary) systems in an article entitled “There are no pickpockets in the desert“. The premise of the article was that open source systems appeared to be more secure because they had not yet had the attention that proprietary systems had had for hacks and cracks. In other words, the hackers had not ventured out en masse into the untapped desert of open source systems.

In November 2005, the Lupper Worm (a significant Linux security vulnerability) was revealed (see “The tip of the iceberg“) and in February 2006 I wrote about “PHP Apps a growing target for hackers“. The trend was clear that open source systems, and particularly PHP applications, were less secure than first thought.

In an article dated 21st December 2006, The Register scrutinised PHP Security to attempt to better understand why this trend is happening and why PHP is less secure that once thought. So it appears now that the hackers have ventured en masse into the desert of PHP applications.

The article raises a number of key points which need to be understood to dispel any myth or bad press that PHP may well receive through misquoting. The main point is:

The majority of security flaws detected in applications written in PHP are not as a result of the language itself, but how it has been used by the developer to build the application.

To quote from the article:

A search of the database, maintained by the National Institute of Standards and Technology (NIST), found that web applications written in PHP likely account for 43 per cent of the security issues found so far in 2006, up from 29 per cent in 2005. While flaws in the language itself account for a very small percentage the total, the problems with PHP underscore the difficulty that developers - many of them amateurs - have in locking down applications written in the language, said Peter Mell, senior computer scientist for the NIST and the program manager for the National Vulnerability Database.

The message to clients is very clear - security is paramount on the Web and it is more complex to build better security in a web application than it is in a standalone desktop application by the virtue that the website (application) is exposed to anybody and everybody 24 hours a day, 7 days a week, 365 days a year.

So, is ASP or .NET inherently any more secure? Some would argue that this is the case, but it is actually the Web environment itself that creates many of the security issues and not the language itself. Here are some of the top security issues that affect a Web application:

• Cross Site Scripting (XSS): This is where a hacker uses a script to auto-complete forms on your site to add information to your web site. This is a common technique that hackers use to post spam to forums or via your “contact us” form.
• SQL Injection: This is where a hacker abuses a form on your website (often login forms) to append database code to the script and reveal information about your users, and/or change or delete data.
• Data Validation: Any information input into a form or appended to the query string needs to be checked and double checked. If it’s not in the range that’s expected the application will have undesirable reactions (see SQL Injection above for example).
• Don’t store passwords as plain text: This may be “nice” because it’s easy to look up a password, but it’s also easy for hackers to do this. Always encrypt passwords.
• Encrypt sensitive data: Even outside of the database! Any sensitive data should be encrypted (or at the very least obfuscated) to avoid discovery or abuse. However, on virtual hosting systems (see “Types of Hosting“) this is not always possible due to the security restrictions that ISPs impose on you to prevent their systems being hacked.
• Do some server housekeeping: Check the settings and make sure the server is set up securely - for example turn “safe mode” on (for PHP) and restrict other unnecessary services.
• Use sessions: If you need to store data securely, use server-side sessions to handle this. However, don’t use cookie-less sessions as this exposes you to session hijacking. A standard cookie-based approach is recommended as no sensitive data sits on the visitors machine, but the session is secured to their visit only. A cookie-less session means that the session data can be easily exposed.

The key thing to ensure is that any web application development takes into account these security issues (and any others the client’s particular application requires) and builds in a secure architecture. Remember that integrating any third-party applications (such as phpBB, the open source forum system) may expose you to unexpected security vulnerabilities and/or require constant upgrades to keep ahead of the security problems that may be found with such applications. For PHP, the book “Essential PHP Security“, written by the internationally recognised PHP security expert Chris Shiflett and published by O’Reilly, provides an excellent synopsis of the key security issues affecting PHP applications and their hosting environment, as well as a recipe book of methods for how to deal with them.

You may initially be shocked at the cost of what appears to be a small web system, but the cost of a lack of security for your business may prove to be more expensive in the long run. Once you get beyond a basic Level 2 marketing site (simple meaning not requiring a database or forms) on our Internet Maturity Model, you need to consider security seriously.

Unless you have money to burn, don’t. It’s not worth it.

We’ve been asked a few times to build systems that store credit card data locally on the website because it’s convenient for the client to do it that way, or their product/service cannot be billed immediately.

The key reason not to store the information locally is one of liability.

Imagine that the credit card information that was stored locally was stolen from your site … you’d be potentially liable for all losses on any of the credit cards stolen. That could be hundreds of thousands of pounds and I doubt if your insurance would cover it. Plus it would probably mean the end of your online business, not to mention the risk of closing you down. Remember there are also broader issues of identity theft which could carry a liability also.

There are also data protection compliance issues. Depending on how you store the information you could range from compliant to non-compliant. Any non-compliancy only exacerbates your liability. Remember too that these data protection issues also extend to how your staff access the system and how easily it would be for an employee to grab the data, leave/pass it on� and compromise your organisation … for organisations that have many staff, multiple access points� and higher turnover rates, this is a very real issue.

Then you also need to consider Payment Card Industry (PCI) Compliance. This is complex and difficult to achieve properly, and unless it is done properly then you will be violating your bank’s merchant agreement. At the moment the PCI is pursuing Payment Service Providers (PSPs) for DSS compliance but after this year, they should be ready to move on to enforcing it with merchants directly (ie the online stores). The six sections for PCI compliance are:

1. Build and Maintain a Secure Network
2. Protect Cardholder Data
3. Maintain a Vulnerability Management Program
4. Implement Strong Access Control Measures
5. Regularly Monitor and Test Networks
6. Maintain an Information Security Policy

From a technology point of view, it can be done. Here’s one scenario to consider.

Install an SSL certificate and a second secure server running behind a firewall, preferably with a nonpublic IP address and no default route set, which is inaccessable directly from the web (and maybe go as far as to have a dedicated crossover cable between the two servers). The second secure server� runs a dedicated SQL server that the webserver (website) can only insert into - no selects or other access. The website itself should be running on its own server (dedicated IP) so that there is no risk of security breach from other sites that share the same IP address.

For larger companies, this may be a viable option and a requirement. But security is not cheap and you have procedural considerations to consider. For smaller companies with more restrictive budgets, you should only ever consider using a third-party payment gateway to take credit card information.

Payment gateways such as Protx allow you a secure integration with your website, manage the credit card information for you securely, mitigate the liability risk, include deferred payment options (so you only bill when you ship)� and only cost a £20 per month flat fee.

The cost of developing your own system, not to mention the hardware and annual support costs is significantly higher than using a company that has already invested huge sums of money to ensure security. And don’t forget the lurking liability costs too.

Back in August 2005, we wrote about the potential vulnerability of Linux systems in our article entitled There are no Pickpockets in the Desert. Although Linux itself remains strong, systems deployed on Linux are receiving more and more unwanted attention from hackers and crackers as reported by Netcraft:

Security holes in PHP-based content management and forum apps are an increasingly active front in Internet security, as hackers target unpatched weaknesses. The latest example is Monday’s hack of chip maker AMD’s customer support forums, in which an older version of Invision Power Board was compromised and used to distribute malware using the Windows Metafile (WMF) exploit.

Internet criminals have targeted unpatched vulnerabilities in open source CMS apps including phpBB, PostNuke, Mambo, Drupal and others, hoping to build botnets for use in phishing scams and distributed denial of service (DDoS) attacks. Compromised web forums hosted more than 600 phishing spoof sites identified by the Netcraft Toolbar Community in 2005 (as noted in their Year in Phishing roundup).

The tip of the iceberg? Maybe.

But effective software development of [bespoke] applications, whatever language they are written in, should take account of the environment that the application is to be deployed in and build in security systems as appropriate. It is also true that no software can be 100% secure, it’s just that the Web exposes these vulnerabilities so much quicker and with more visible consequences. How secure you decide to build an application will depend on the risk associated with compromise, and is also affected by budget constraints. However, professional software development should not be confused or compared with inexpensive freelance work, as the latter is often not developed to the same standard. I use the term inexpensive deliberately as there are numerous freelance developers who produce excellent work which can be more secure than other systems. It’s a case of using the right tool for the job! Remember too that much open source software is developed for free by talented people and is distributed for free to be used “as is with no warranties or liabilities”. As the old adage goes, “you get what you pay for”.

Link to full Netcraft Story.