Securing the Internal Network

Securing the Internal Network

ByBob Williams

SecureWiFi Networking Consulting

The goal of this document is to define new guidelines in order to improve the security in Microsoft Windows-based internal networks. In order to be useful in real situations, these measures have been implemented to obtaining the lowest-cost possible approach, and to prevent such a project to become financially prohibitive. Security being a field in constant evolution, it is possible that new solutions can be integrated to these ideas in the future.

Introduction

One of the first things you learn when you start looking into computer security is that about 80% of the attacks reported on networks come from the inside, principally from fired or disgruntled employees, from external consultants or from malicious hackers that got inside the network one way or the other (non-secured Internet connection, plugged-in modems, social engineering, got hired by the victim under false pretensions, etc.). Since the inception of the Internet, this number tends to lower, but latest estimates still show that between 60%-80% of network incidents happen on the internal network. The majority of computer security companies will put most of their efforts on securing the periphery of the network, while leaving the internal network itself completely open. A lack of consciousness about this problem, or by lack of competence, or more often, by lack of money for a project affecting all workstations on a network, the internal network takes a low priority.
I could see for myself on a few occasions, that once the periphery of the network is circumvented, the rest of the network is just like a big ripe fruit that we simply have to pick. This is why it is imperative to define measures that will enhance the global security of computer networks, while trying to keep the costs as low as possible. This is possible with the help of optimizing the tools that are already in place and by automating the deployment process. Automation is the preferred method as it reduces cost and the possibility of human error.

Definition of the multi-level approach

We often hear that computer security is not a product in itself, but more of a process that we constantly have to review due to the quick evolution of the technology and the vulnerabilities that might come with it. This is why it is recommended to implement multi-layer security architecture on your network, in order to prevent having a single point of failure. This is the strategy I chose to follow when I wrote this document. Not only the act of securing the internal network is part of a multi-layer strategy, but the multi-layer strategy will also be applied in order to secure the network.It is important to mention that the measures described in this document apply principally on securing Windows workstations. These measures can also be applied on Windows servers, but server administration implies other measures that are out of the scope of this document. Also out of the scope of this document are the measures to take to secure the periphery of your network, such as firewalls and IDS (Intrusion Detection System). Even if these measures are not covered in this document, it is important to take these into account in a global computer security strategy.
There is a bit of common sense that says "There is a conflict between ease-of-use and security." In order to have an efficient result; the solutions proposed must find the balance between these two concepts. In the case of Microsoft Windows, I think there is enough fat in the ease-of-use side that we can cut in it generously and this way re-establish the balance between ease-of-use and security. The different concepts that I will explain later are in part derived from my previous whitepapers, and in part from recent experiences. More precisely, this document will speak of antivirus protection, personal firewalls, securing the operating system and the various applications used on workstations, and various deployment techniques that can be used to facilitate the task.

Maximizing antivirus protection

For a long time, it was believed that a good antivirus and a firewall were all that was necessary to efficiently protect a network. Of course, this is not true anymore, but we must not neglect an antivirus solution as a means of securing our network. It is important to know that an antivirus application is not a panacea, and that it is easy for someone who knows about antivirus to circumvent such an application (which is why we are taking a multi-level approach). It is even more important to know that in order to be efficient, the antivirus product has to be regularly updated and properly configured.
In most of the cases, default installation is the norm, and this kind of configuration usually leaves holes in terms of antivirus protection. Sometimes we see antivirus installed only on critical machines or servers. Every workstation on the network should be equipped with antivirus, even if your mail server is equipped with antivirus and content-filtering products. All that is needed to compromise the security of a network is a single vulnerable machine, so it is necessary to define protection measures that take this reality into account.
In order to have maximum protection from your antivirus product, the chosen product must be able to scan files and programs in real-time in memory as well as files residing on the hard disk. Practically all antivirus products offer this functionality today. It is important to configure the antivirus product in order to scan for every type of file. It is very easy to camouflage a virus to look like an innocuous file (I Love You, Life Stages and Anna.Kournikova are good examples. With the processing power available in today's machines, there is no reason not to scan every file on a machine. You may have to put some exceptions however, depending on your environment (for example, I exclude for scanning my .pgd encrypted disk file). If the software lets you do so, you should also scan compressed files. If the antiviral software offers a heuristic detection engine on top of signature matching, then you should enable this also.
What good is it to put in place protection measures if we are not in a position to evaluate their efficiency? When default configuration is in place, it means that in the best of cases, the software will write its log files on the local hard drive on which it is installed. Some products gives you the possibility to chose the destination of your logs files, preferably on a central server (often a simple UNC path like \\centralserver\sharedfolder will work). I strongly recommend the use this functionality, as it will increase your capacity to understand and evaluate the scope of a virus infection when it happens, without having to hop from machine to machine to review log files. In a crisis situation, such a setup saves you time and gives you the global picture, which is essential while trying to stop the crisis. If the software also lets you send alerts by e-mail or pager, then it should be turned on. This will notify your staff as soon as an infection occurs, and from their desk they can easily check the centralized log files and make the call: simply an old virus that got cleaned on the way to the network, or a large-scale infection prompting for more immediate action? Some products do not let you change the log files destination, which means that good products may be overlooked simply because they lack this feature. To solve this, there is LogAgent, a program written in Perl that will monitor log files for changes, and will forward these changes to a central location.
The last aspect to consider is the updating of the antivirus definition files used by the software to identify the possible viruses that could try to get on your network. Because of the way that signature-matching works, if a virus signature is not included in the signature database, then chances are good that it will go undetected (heuristics tries to solve this problem, but can induce the possibility of false alarms). Usually, the software will be configured to be updated once a month, fetching its files directly from the vendor's website. Depending on the level of paranoia expressed by your company (and the rapid growing rate of virulent activity), this should be done daily or weekly, and the updates should be done from an internal server, where the network administrator has previously put up-to-date files. This will prevent network congestion. I will cover later in this paper how to deploy your solutions on your network containing your custom configuration.
One last word relative to virus protection: for the past 4 years or so, virus writers primarily focuses on exploiting some flaw in a well-known software in order to propagate their piece of malicious code. The most dangerous is Outlook (and its cousin counterpart, Outlook Express). This software, which features functionality such as e-mail, agenda, calendar, and so on... sports multiple vulnerabilities. It the number one choice for virus propagation. Before Outlook, it was considered impossible to get infected by a virus simply by reading e-mails. One had to open an attachment in order to be infected. Anyone pretending the opposite would quickly be made fun of and proved to his peers that he didn't grasp the mechanics of computer science. This is not true anymore since the coming of Outlook. Because of this new functionality (others would say vulnerability) all things are now possible.
It is very hard to secure Outlook in order to make it inoffensive, and on top of that, the default configuration (which is highly insecure) is the most used in companies. For these reasons, many companies will put in place several antivirus utilities on various points on the network architecture. These utilities are for the most part useless against new, unknown threats. The analogy of a chain, where the weakest link is the one that will break when the chain breaks, is often applied in the world of computer security. By strengthening all the other links in your computer architecture (antivirus on servers and workstations, mail filtering, etc.), but keeping the weakest link on your network (Outlook), then you can only be sure that the chain will break with yet another wave of Outlook virus. I know that what I am saying here is not popular, but if you really make a big step forward in virus protection, ban Outlook and Outlook express from your network (and I point here to the clients, not the Exchange server, which can be used with other mail clients).

Setting up personal firewalls

For a bit more than 2 years now, a new kind of software has made an appearance in the computer security market, personal firewalls. These are numerous and vary in their functioning from one product to the other. For this reason, I recommend that you research which products are available and evaluate how they work, in order to find which one best suits the needs of your company. Personal firewalls don't all behave the same, and it is on this point that I'd like to expand a bit. Let's take for granted that there is a firewall protecting the internal network from the Internet. What would then be the advantage of installing a personal firewall on a PC that works on the same principles as the main firewall, that is a firewall that filters incoming and outgoing traffic based on rules defined on some characteristics of the concerned IP packets? A packet sent by a malicious person that achieves a pass on the firewall, because it conforms to the rules put in place, has all the chances to do the same when it is confronted with the personal firewall. Since the chances are great that the packet will also conform to the rules of the personal firewall, unless the rules from the two types of firewalls are sensibly different, the packet has a pass.
Another strategy, that I find particularly interesting, is a personal firewall that manages incoming and outgoing traffic based on the permissions set for the application requesting the connection, in opposition to the source and destination of IP addresses and ports. This type of firewall also makes a difference between the internal and external network, which makes it possible to obtain a good granularity on the type of traffic accepted or refused. On top of that, this type of firewall is made to stop right from the PC any connection attempt made by Trojan horses, denial-of-service agents, and some spyware. It is possible, for each application on the PC, to authorize, to refuse or to ask for permission for each connection, either on the internal or external network. It is possible to determine which applications have the permission to act as servers, which means that it can accept connections from other machines on a specific port. Applications not defined in the permission list will always ask for permission by default.
By this design, if a Trojan horse gets on the PC via an e-mail attachment, it will never be able to receive the connection requests sent by the malicious hacker, even if this one is located on the internal network. The danger with this strategy is to be too permissive with your applications. For example, if we leave the command prompt FTP tool, then it is possible for a cracker to craft a Trojan horse that will use the FTP tool on the victim PC to send collected information out of your network without triggering any alarm. Other scenarios using other commonly used software are possible. In the end, it comes down to the risk exposure you can cope with. But still, be careful when designing your rules. At a minimum, all command prompt tools should at least ask for permission, as they offer no graphical hint of their usage. At the least, your personal firewalls will work as a complement to your main firewall, instead of just being a redundancy of the same strengths and weaknesses.
In order to increase your network security, I recommend the various servers on your network become the "internal network". This way, it becomes impossible for a workstation to connect to another workstation on your IP network. This will force all electronic communications to transit via your servers (file server, print server, mail server, DNS, firewall, etc.) before getting to its destination, and makes it impossible (*) for an insider to hack into someone else's PC via the network.
Certain products will still let you associate specific ports to each application, which gives you one more degree of granularity in your setup. Of course, in order to be efficient, we must have a good idea of what is installed on the workstations, and which network these applications should be allowed to connect with. By enumerating the applications allowed for network activity (you should have this detailed in your corporate security policy document), it then becomes easy to put standards that prohibits unwanted applications, such as chat clients, and instant messaging. To achieve this, the configuration has to be protected by a password.
As with antivirus, it is a wise choice to centralize your log files and keep and active eye on them. We will see later how to make pre-configured installation packets to deploy your personal firewalls effectively.

Optimizing operating system security

Here we will discuss one of the most problematic aspects about securing the internal network, securing the operating system on each workstation on the network. Why is securing the internal network often left undone? It is a relatively complex task, and it traditionally needs to be done by hand, machine by machine, which implies high costs for workforce and is prone to errors. Corporate IT departments usually don't have the required knowledge necessary to deploy securely configured PCs in the first place, and even if it is the case, it often needs to checked and updated.To give you an idea of the size of the task, there is the deactivation of the guest account, forcing a complex password for the local admin account, removal of unnecessary services and components (such as the Posix and OS/2 subsystems), restrict access to the LANManager hash, restrict access to folders and registry hives, applying service packs and fixes, just to name a few. The list is rather long, and it is easy to understand why this aspect is so often left aside: the time required to do all this manually on all PCs on a network is an enormous task.
In order to solve this problem, Pedestal Software created a graphical interface tool, called Security Expression. This tool lets you audit and configure remotely Windows NT and 2000 machines by comparing it to a set of pre-defined security policies that correspond to the secure configuration we wish to obtain. (I tried to stay vendor-independent in this article, but I actually don't know of another similar product.). There are some sample configuration files that come with the program, and more you can download from the company's website. One of the sample files corresponds to the recommendations made by the SANS Step-by-Step, another one corresponding to the "Microsoft Security White Paper", and three others corresponding the standard US Navy configuration for workstations and servers. These files are redundant in the fact that they cover at least partially the same holes, I prefer the Navy files. They are more thorough, and you can modify to suit your needs.
This software doesn't need any installation of agents on the workstations. We only have to install it on a machine that is connected to the network (administrator's machine is a good idea), and we simply have to give it the administrator's login information of the domain we want to secure. The software will then proceed to a complete scan of the machines on the domain, matching their configuration against the security policy we want to implement. Once the scan is complete, the program presents an easy to understand report that shows item by item if the configuration complies with the security policy or not. With a single click of the mouse, we can start a similar process that will take care of modifying the workstation configuration to make it comply with the security policy, thus securing the various parts of the operating system on each workstation. We can also use Security Expression on a regular basis to test the integrity the configuration base, or to update new policies to cover newly discovered vulnerabilities.
Security Expression passes its requests by using the NetBIOS protocol, which is the basic protocol in a Microsoft Network, along with the administrator's credentials, to audit and configure the workstations. It is also possible to create your own configuration files, which can be drafted from the sample files that come with the program. In its simplest usage, Security Expression can add, modify or delete registry keys, user accounts and groups, files or ACL's, and probably a bit more. It is possible to include scripts or programs to give you more tools to deploy your secure configuration. You can also use this to deploy service packs and hotfixes, or other programs like the ones that we discussed above.


Optimizing applications security

So far, we have taken steps to try to protect against viruses, Trojan horses, DoS agents, and we have considerably secured the operating system environment in order to reduce the number of vulnerabilities in the network. We could be thinking that our task is coming to an end, and that we have finally leveled the challenge of securing our internal network. Not yet.. We still have to take into account the various applications that the users need to conduct their daily business, which could also host several flaws that could compromise the security of our network. Remember the Outlook example I gave you? It is true that with all the steps we have taken so far to secure our network, it could be harder for a potential intruder to achieve its goal. As long as there is an open door, there is always a way to make it open wider, and wider, up to the point to it will circumvent all our previously taken security measures.
Another application that needs a special attention is the web browser, be it Internet Explorer, Netscape, Opera or other. It is important to reduce the capabilities of this type of software, because it is an open window on your network. For example, it could be dangerous to accept blindly the execution of Java, JavaScript or VBScript applets. Also, the acceptance of ActiveX controls is renowned as being non-secure. These controls give the possibility to web authors (anyone) to execute code on your machine without restriction. It is important to take preventive steps to filter these possibilities, but still leaving enough room for an enjoyable web experience. Again, risk-exposure acceptance is a key factor here. E-mail applications also need similar adjustments, such as the de-activation of VBScript execution in HTML message for example. If you can, disable HTML mail altogether if you want to sleep tight at night.
In fact, each application installed on your machines that connects in one way or the other on the network should be the object of specific research on how to remove known vulnerabilities. The same could be said of application software that has the capacity to execute code under one form or another. One such example is the popular word processing Microsoft Word, which has the ability to execute macros (and was at the origin of a new breed of viruses). Once the risk factor associated with each standard application on your internal network machines have been identified, and that the necessary changes have been thoroughly tested and approved, we can once again use Security Expression to deploy the configuration changes on existing machines.

Deployment

In a security context, the ideal situation is to reformat the machines and reinstall everything from scratch and secure everything before putting the machines on the network. In real life this is simply too costly for many companies, and is a huge task to undertake, not to mention lost productivity usually encountered in big deployment projects. So the next best thing is to secure the existing machines with the different tools covered so far in this paper, and take the bet that these new security measures will be able to stop, or at least detect, any previous security breach.
As we have seen, it is very costly to make an enterprise-wide software deployment by going from machine to machine (I still often see it done this way), and it opens the door to human mistakes. In the case of a simple configuration change, we have seen that Security Expression was letting us do the changes remotely. It is also possible, with the use of scripts, to use it to deploy software. Another approach that I favor particularly is to create custom installation packages according to our specifications (with an application like InstallRite, which is free). The installation of this custom package on a machine will not need any other effort to make its configuration match our specifications.
InstallRite works by taking a snapshot of all your hard disk and registry content, before and after the installation of your software, and identifies the changes made to the system by the installation (files or registry keys that have been added, removed or modified). It can then extract these files and registry keys and create a self-extract program that will automatically install the software with the desired configuration. The trick is to configure your software before taking the second snapshot of your system. You can use this to deploy your pre-configured antivirus, personal firewalls and any other productivity software you may want to deploy. The installation itself can then be launched from the login script or any other method you prefer.

Costs and savings

So far, I only have covered the technical aspect of such a project, neglecting the financial aspect for text clarity. You should already have a good idea of where the costs are going to come from: software licenses. Indeed, you will have to account one software license per workstation on the network for each application that you want to deploy. Cost reductions are achieved by checking for applications that can be reused (antivirus, for example) and by simplifying deployment procedures. The same is true for Security Expression, since its license is based on the number of machines of your network. For bigger networks, a corporate license is usually available and can offer a good licensing alternative.
The other cost-factor is workforce. Everybody knows it; qualified technical workforce is rare and expensive. This is why it is important to have an efficient deployment scheme to simplify the task and reduce the number of staff needed. We can easily count between 1 hour and 1 hour 1/2 per machine for a technician sitting at a machine and implementing mechanically all the things covered in this document, on top of the time necessary for the initial analysis phases of the project (identification of standard software, definition of configuration, tests, etc.). It is a complex and repetitive task that is error-prone and where mistakes can leave a big hole open in the network that you worked so hard to secure. By automating the task (the same analysis phase is still necessary) the deployment time can be drastically reduced to approximately 5-15 minutes per PC for the same amount of work, depending on various technical factors like processor time and network speed. Nonetheless, the saving in time and workforce is enormous, given the level of security obtained by these measures.
Integrated commercial solutions vs. independent products
I talked about various types of tools as independent entities. There are some commercial integrated solutions for workstation security, which include an antivirus, a personal firewall, VPN, encryption and IDS system. These applications are all optional components that can be added or modified at will via a common central interface. In fact, the graphic application that manages this multi-tool solution is not very different from what we have seen, but has the advantage of showing a common interface and tool to configure and deploy all these solutions.
Even if an integrated solution has some advantages, it also has a few inconveniences. One of these inconvenience lies in the fact that the distribution of the software packages is more complicated than it should be, and you may have to launch your installation routine a few times to cover all the machines in the network. Another inconvenient is that the interface that shows the log files doesn't do anything more than simply show the log text, and sometimes it does so in a clumsy way. Nothing beats looking at the log files with a good text editor. The biggest problem is probably the fact that vulnerability present in one component can mean that vulnerability is also present in another components of the suite. That means that it can be exploited to shut down the integrated solution altogether. Using different products from different vendors doesn't necessarily guarantee that such a thing can not happen, but vulnerability present in one product has a minimal chance to have an impact on the other products.

Conclusion

In this document, I wanted to discuss a problem in computer security that is often overlooked, either for technical or financial reasons: the security of the internal network. More than half (and even near 80% according to certain sources) of reported computer security incidents are done from inside the network. This is at least partially in contradiction to measures traditionally implemented to secure a network, habitually against outside attacks (firewalls, IDS, content filters,...). Although these measures are necessary, they are for the most part useless in the scenario of an attack coming from the inside. They become useless as well if an outside intruder finds a way to circumvent them. The biggest challenge while securing a Windows-based internal network remains the complexity of the task and the volume of machines affected. For these reasons, the cost associated with this kind of project is often judged prohibitive, and is left aside as a result
I have shown with this document that with the different tools available and with a little imagination, it is possible to obtain an appreciable increase in security on the internal network, for only a fraction of the price normally associated with this kind of work. We now have deployment solutions that make it affordable enough to interest companies who would like to protect their data assets.

Windows Root Kits a Stealthy Threat

Hackers are using vastly more sophisticated techniques to secretly control the machines they've cracked, and experts say it's just the beginning.

By Kevin Poulsen, SecurityFocus Mar 5 2003

Barron Mertens admits to being puzzled last January when a cluster of Windows 2000 servers he runs at an Ontario university began crashing at random. The only clue to the cause was an identical epitaph carved into each Blue Screen of Death, a message pointing the blame at a system component called "ierk8243.sys." He hadn't heard of it, and when he contacted Microsoft, he found they hadn't either. "We were pretty baffled," Mertens recalls. "I don't think that cluster had bluescreened since it was put into production two years ago."
Mertens didn't know it at the time, but the university network had been compromised, and the mysterious crashes were actually a lucky break -- they gave away the presence of an until-then unknown tool that can render an intruder nearly undetectable on a hacked system. Now dubbed "Slanret", "IERK," and "Backdoor-ALI" by anti-virus vendors, experts say the tool is a rare example of a Windows "root kit" -- an assembly of programs that subverts the Windows operating system at the lowest levels, and, once in place, cannot be detected by conventional means.
Also known as "kernel mode Trojans," root kits are far more sophisticated than the usual batch of Windows backdoor programs that irk network administrators today. The difference is the depth at which they control the compromised system. Conventional backdoors like SubSeven and BO2K operate in "user mode", which is to say, they play at the same level as any other application running on the compromised machine. That means that other applications -- like anti-virus scanners -- can easily discern evidence of the backdoor's existence in the Window's registry or deep among the computer's files.
In contrast, a root kit hooks itself into the operating system's Application Program Interface (API), where it intercepts the system calls that other programs use to perform basic functions, like accessing files on the computer's hard drive. The root kit is the man-in-the-middle, squatting between the operating system and the programs that rely on it, deciding what those programs can see and do.
It uses that position to hide itself. If an application tries to list the contents of a directory containing one of the root kit's files, the malware will censor the filename from the list. It'll do the same thing with the system registry and the process list. It will also hide anything else the hacker controlling it wants hidden -- mp3s, password lists, a DivX of the last Star Trek movie. As long as it fits on the hard drive, the hidden cargo doesn't have to be small or unobtrusive to be completely cloaked.
Slanret is technically just one component of a root kit. It comes with a straightforward backdoor program: a 27 kilobyte server called "Krei" that listens on an open port and grants the hacker remote access to the system. The Slanret component is a seven kilobyte cloaking routine that burrows into the system as a device driver, then accepts commands from the server instructing it on what files or processes to conceal. "The stealth driver in my mind is the scary concept," says Mertens. "You can hide an elephant with it."
Root kits are old hat in the Unix and Linux world, but are rarely found on hacked Windows hosts. "They're a scary thing," says Marc Maiffret, chief hacking officer at California-based security software-maker eEye. "In Unix that's been going on for ages, but the backdoors for Windows NT have always been trivial. I've always wondered why this isn't happening."
Cloaking Device Driver Greg Hoglund, a California computer security consultant, believes intruders have been using Windows root kits covertly for years. He says the paucity of kits captured in the wild is a reflection of their effectiveness -- not slow adoption by hackers. "It's happening now," says Hogland. "People don't realize that it's happening, but in the next two or three years we're going to see a lot more of this activity."
If there's an authority on Windows root kits, it's Hoglund -- he's been sounding the alarm about their malicious potential since 1999, when, as a proof of concept, he wrote one himself called "NT Rootkit." Since then he's collected and analyzed three others: "null.sys," "HE4Hook," and a kit called "Hacker Defender," all of which he makes available on his Web site, Rootkit.com. (Hacker Defender, oddly, is also available for download from CNET Asia.)
"For all of those, I'm absolutely, one hundred percent positive that there's probably ten more that we haven't seen publicly," says Hoglund. The skills to write a kernel mode Trojan are not beyond the reach of the average programmer, he says; last month Hoglund taught a seminar on the topic at the Black Hat security conference in Seattle, and by the end of the two-day course, "Every student in the class was writing their own root kits. They were hiding process and files, hiding directories, and call-hooking."
Once Slanret is installed on a hacked machine, anti-virus software won't pick it up in a normal disk scan. That said, the program is not an exploit -- intruders have to gain access to the computer through some other means before planting the program.
Despite their increasingly sophisticated design, the current crop of Windows root kits are generally not completely undetectable, and Slanret is no exception. Because it relies on a device driver, booting in "safe mode" will disable its cloaking mechanism, rendering its files visible. And in what appears to be an oversight by the kit's author, the device driver "ierk8243.sys" is visible on the list of installed drivers under Windows 2000 and XP, according to Symantec Security Response (SecurityFocus is owned by Symantec). McAfee reports that a running service named "Virtual Memory Manager" with a blank description field is visible on a compromised host. And, of course, there are reports that the root kit sometimes crashes servers.
Hoglund says future Windows root kits won't suffer from Slanret's limitations. And while he says the risk can be reduced with smart security policies -- accept only digitally-signed device drivers, for one -- ultimately, he worries the technique may find its way into self-propagating malicious code. "My street knowledge, my gut feel, is there are probably already worms or viruses doing this now," he says. "We just haven't seen them."

Tool Kits for the Security Professional

Tool Kits for the Security Professional
By Bob Williams

SecureWiFi Networking Consulting

The Power of Linux
All distributions of Linux and Unix derivatives are the operating system of choice for the security professional. Even if you are not fully versed in command line functions of these systems, the windows type inter-faces that are offered for these operating systems make using applications a very intuitive process. The open source community has introduced many new and innovative ways to examine security in networks and applications, and to help build and maintain robust software for every user. One of the latest favorites is a distribution of Debian on a bootable CD-ROM. These distro’s boot into memory on just about any x86 PC. Nothing is written to the computer’s hard drive and the operating system does all of its work from the CD-ROM. You can use command line or a windows type inter-face to run any application included with the distribution. Most of these operating systems support NTSF file formats. Therefore, you can mount the computer hard drive as you would any memory device. This feature comes in very handy when you need to do a forensic examination of a hard drive. The hard drive will remain in its original state throughout a complete examination.

Network Scanner Programs

A full feature Network Scanner is a must have for the professional toolbox. The scanner should be configurable enough to detect all of the protocols on a network, whether wired or wireless. There are several to choose from commercially or open source. The feature set can include options to apply patches and upgrades remotely, and to monitor connections in real time.

Packet Sniffers

The Packet Sniffer has gotten some bad press lately, but it is still a valuable tool for the professional security analyst. If the aim of the analysis is to ensure that data flows, as it should, to the destination that it should, then packet sniffing is the technology of choice. When network security hinges on secure data transmission to a specified destination, and no other, packet analysis is the method that will give the most complete information about IP routing and hopping inside the network.

Wireless Access Point Auditing

Mobile computing is becoming more pervasive and more desirable with every new rollout of the latest hardware. Intel is now the driving force with its Centrino configurations for laptops. This is in turn, is making the proliferation of wireless access points a major problem for network security. Rouge wireless access points inside the wired enterprise network now represent the gravest risk to enterprise security. There are several software wireless access auditing tools available commercially and from open source that are robust and full featured. There is also a variety hardware type radio signal monitors that can be a starting point to determine if a problem is evident.

Password Recovery and Management

Password management is an often over-looked tool for the security professional. When a client needs to be sure that access management is configured to the highest possible security standard and only the people authorized to have access to sensitive material are indeed the only ones, then password management tools become important. It is important to manage server resources to deliver the data and applications to the right people at the right time, and password management of those resources is another layer of security for an enterprise environment.

A White Paper : Secure Application Development

Secure Application Development

By
Bob Wiliams
SecureWiFi Networking Consulting

Security and Software

Although software development encompasses a large variety of possible efforts, the need for security is common across all of them. Strong security is a continuous process that arises from comprehensive and well thought-out design and development methods and a continuous analysis throughout the life of the application. Although there is no such concept as guaranteed security, the goal is to create software with security in mind and establish a high degree of protection that makes attack and exploitation difficult and unfeasible.

Here are several guidelines that assist in evaluating and bolstering security of an application or product through the phases of the development cycle. The approach used here differs from common practice. Many sources of information on secure application development focus on the technicalities of the code and implementation, while ignoring other elements of the process. Security in an application comes not only from the code used to create it. It begins with the idea for the application and carries through the design and implementation phases to form a cycle of security analysis. Each of these phases depends on the other to provide the highest level of application security needed and possible. This cycle continues throughout the application’s life-span and should be considered with each new incarnation, enhancement, or modification. Software developers and engineers need to understand methods to design and write code with security in mind, as well as the security issues that might arise from their efforts.

Although this paper focuses primarily on Internet related applications, the concepts here are applicable and important to all forms of software development.

Developers achieve security awareness and thoughtfulness through careful implementation and an aversion to pitfalls. At the end of this paper, you should be able to establish a procedure for secure application development that includes the creation of a security architecture and the ability to examine the design and implementation for relevant security issues.

What is a Secure Application?

A secure application emphasizes thoughtful analysis, diligent design and a focus on implementation. It’s developers consider the security issues of similar applications and analyze innovations for new risk areas while balancing the level of security required by the users. To make this happen, it is useful to know the effects of insecurity on an application.

Is the Enemy Within Your Own Code?

Common attacks such as DoS, buffer overflows, and race conditions can plague applications with poor methods of input validation and data protection. This is a brief overview of common vulnerabilities.

Configuration Issues

Security problems with configuration of an application and the environment in which it runs are very common. Applications often store configuration information in a file or database, write runtime information to other files, and provide multiple services simultaneously. Default configurations can be very dangerous, but are there to help users run the application with the least amount of effort. This leaves the application open to attack.

There is a disadvantage to having every option turned on by default, although it does demonstrate the rich feature set for the user. If a vulnerability is discovered, the user is unknowingly at risk. Think carefully about which options are enabled for regular operation and which should remain disabled.

Race Conditions

As the name indicates, a race condition is a window of opportunity in a running application that enables another process or application to exploit the privilege or functionality of the first. Race conditions can occur when complex or multi-step procedures run, when an application interacts with other processes or resources, or when functionality is poorly organized. When an application is able to escalate it’s system privileges beyond the user privileges, and is unable to relinquish to the user configuration, another service or application that was elevated with it may be compromised and be available to an exploit.

Before creating a function that requires higher privileges or performs complex interactions with components outside of the application, take a moment to organize the functionality and find an efficient way to write code.

Buffer Overflows

The buffer overflow is probably the most notorious and dangerous condition that can occur. Forget the fact that buffer overflow can crash an application and destroy data with invalid inputs. Buffer overflows can be crafted to execute a functionality that was never intended. Processes and services can be accessed as Admin., or Root directly from a buffer overflow condition.

Examine every memory allocation for variable string inputs to make sure that variables have valid parameters with the correct null values.

Data Protection

The scope of data protection is broad. It extends from the internal methods of an application out to the operating system and all of the systems to which it connects. This description focuses on the data protection within an application and the operating system in which it runs. These concepts can be extended to interconnected systems.

It is important to remember that, in most cases, the application and its operating system are using the same physical processor and memory. While this might seem obvious, the security ramifications are often forgotten. A developer cannot assume that the memory used by the application is accessible only by that application. The underlying operating system controls access to memory and therefore has access to all available memory, whether used or unused. If an application is using and manipulating information that should be kept secret, it is vital to protect internal data. Without the proper protection and initialization, exploiting operating system functionality can access this information. Establishing authentication and access control methods can protect data.

Temporary Storage

Temporary storage in files is not itself a vulnerability, but it merits some thought, because it exacerbates the problem of data protection and race conditions.
When using temporary files, check for their existence during initialization of the routine and set permissions to restrict access only to the application. It is also recommended that the file name be randomized to make it hard for an intruder to guess. Finally, remember to delete the temporary file when you are done with it.

Denial of Service Attacks

Denial of service tools are a common form of attack, and can be initiated from the network or on a local system. These attacks exploit a design’s failure to address the negative events in an application. Applications should be developed with an understanding of the functionality they provide and functionality they do not provide. This enables the developer to build safeguards into the application that protect it from denial of service. These attacks come in several flavors, network bandwidth saturation, system resource utilization, and application flaws.
To protect against denial of service attacks, begin to consider where potential vulnerabilities exist in an application. Start early in the design phase and continue the analysis through the completion of the application.

Input and Output Methods

User-supplied or external inputs is the most obvious and prevalent point of entry for attacking an application. Whether data is coming from a network, from a keyboard connected to the system, or from the user environment, the security of the input method demands careful consideration. Application design and implementation must have a defined set of criteria for input. This includes the explicit data type and values that are and are not acceptable, the reaction to unacceptable data, and the path of that data through the application.

Be careful in any application that creates files or accesses the command line based on input. Screen meta-characters out of the input.

Application output can also pose a risk when users blindly write data to files, terminals, or devices. It is equally important to validate output before actually committing the data. The conditions that allow for successful output should be defined and documented to provide a level of assurance within the application that any outbound information is checked.

Criteria for user supplied input should be defined, and associated functionality should be developed to support its validation. This criteria should outline what is and is not acceptable. Any time that externally defined data crosses the boundary of an application or module, it should be validated.

Security Architecture

Security architecture for an application outlines a comprehensive method for the development of reliable and secure applications. It establishes a process and a framework by which the security needs of an application are analyzed, defined and implemented. Here are few components that constitute security architecture.

Components of Security Architecture

Comprehensive security architecture is best achieved through an increasingly more detailed approach that begins from the external viewpoint and progresses through the details of the implementation. Here are some components to organize the information needed for the creation of an application’s security architecture.
1. Risk assessment and response
2. Security requirements
3. Design phase security
4. Implementation phase security

Set the Stage

Assessing the risk of an application requires some diligence on the part of the application designers. The most basic research that identifies the security issues with related applications is a good place to start.
The known vulnerabilities of an existing application can provide hints toward the presence or lack of a security architecture in its design. The vulnerabilities can often be categorized as implementation flaws, design flaws, and functional flaws. Shortcomings in design and function leave holes in the thoroughness of functionality, often creating a security risk.

Consider the Functionality Not Provided

The most basic level of functionality possible is defining what an application does. It is looked at in the most pristine circumstances. It naively assumes that the world is perfect and that nothing bad ever happens when the application is running. All inputs are completely understandable. All network connections are from known clients. All operating systems are sterile and it is what the application expects. Obviously this is not the case in the real world and cannot be expected.
Considering both the positive and negative scenarios for an application’s operation is vital when creating it, The negative view defines the reaction to unknown input, invalid syntax and communications, and anomalous conditions that might occur. The application needs to respond properly to events not expected or defined. Although it is often difficult and infeasible to explicitly handle every known exception, general rules can easily be created to handle undesired events.

Can You Buy Guaranteed Security?

This paper would not be complete without the mention of third-party organizations that provide security software, development kits, and hardware to enhance security of applications. Many of the commercial vendors present their products as providing “guaranteed” security. This is simply untrue; “guaranteed” security is a fallacy. This concept considers security to be a feature or component that can be plugged in for immediate security satisfaction. If only one bit of information is gleaned here, let it be the fact that security is a continuous process.
The inclusion of third-party security technologies should be examined for usefulness and value, given the security requirements that are established for the application.

Security Requirements

In conjunction with identifying related security risks known to a specific applications or genres, developers must assess the security requirements for their own application. This analysis should arrive at a balanced measurement of the level of security required. It does not have to ponder extreme measures. Protecting against known risks and minimizing the number of successful attacks is generally an acceptable level.
To arrive at security requirements, developers can find it useful to concentrate on commonly known risk areas.
1. User authentication and control
2. Data storage of confidential information
3. Security in internal network communications
4. Security of entry points for external applications and operating systems

From these general areas, designers can identify a minimal set of features to analyze. Some risk areas are more important than others, depending on functionality.

Should I Lock It All Down?

It is possible to take application security too far. The performance of the application while it interacts with hardware, operating systems, and networks can be compromised if the complexity of the security measures out-way there usefulness to the original design. This can occur if methods are blindly applied to all components of the application without thought to their requirements. Here is a reasonable starting point to determine a basic security level.

Assessing Authentication and Access Control

Many times user authentication, handled by the operating system, is all that is required.
There are a few classes of application that need to deal with authentication on their own. Embedded applications and distributed Web applications often need some level of user authentication and access control.
Terminal access or network access will determine the most appropriate authentication scheme. The operating system involved should also play a large part in this decision.

Requirements for Data Storage

Data storage reflects the method used to store sensitive information. The correct use of file permissions by the operating system, their location, and encryption, if any, are all part of the data storage arrangement. The nature of the data should always drive the method.

Network and Entry Point Security Requirements

Security of network communication is best addressed by examining the content of the message being sent. Applications that utilize network communication for informational messaging or passing static data may not require anything stronger than the protocol supports. Again, an application that sends sensitive information is likely to warrant the addition of higher security methods. Analysis, Analysis, Analysis.

Network, Application, and System Interaction

Network interaction can be present at several levels. An application can be completely client/server-oriented, for use on remote systems spread across the Internet. The need for security in these applications becomes considerably more complex than a stand alone.
Discern all of the valid dependencies and make a decision from that analysis. The answer to the required security level will probably be somewhere in the middle of two extremes.
The stand alone application may need only non-Internet sockets and IPC mechanisms for related application calls. IP sockets do pose a risk and where possible, they should be avoided for local traffic. Diversion from domain sockets in the UNIX environment is also a consideration when other IPC communication is available.

Operating System Interaction

Interaction with the operating system often creates another level of security issue. The execution of external programs and the use of system and other externally defined calls are common sources of exploitation. Because of their nature, system calls present a high degree of risk when used improperly. Methods to call other applications to run services for the first application are in danger of also calling higher permissions and privileges that once called leave an opportunity for exploit with meta-characters if no validation parameter is in place. The path to Root or Admin will be wide open in this condition. Higher privilege calls should be carefully controlled and returned to minimum as soon a function is completed.

No Security Needed Here

If you chose to ignore security within the application as it is developed and rely on the customer’s operating system or network you are shunning your responsibility to provide secure applications to the public. The security philosophy advocated here is for a strong and comprehensive security ideology that assumes nothing about the components, external to the application. An application should always be as secure as it can be with respect to itself and the external components with which it interacts. The level of follow-through is left to the discretion of the developer and designer.

Identification of Risk

The place to start a risk assessment is to classify possible attacks.
1. Subversion of the application
2. Subversion of the system and external applications
3. Cessation of functionality

The first class of attack has the goal of gaining control of the application or the system it runs on. Failing that, the application can simply crash, or crash the system with it.

Subversion of the system is a wider goal because the compromised application is a conduit to other more useful components for the attacker.

An application can completely cease to function and crash due to attacks. This is a form of denial of service.

Security Response

After the risks and requirements are identified, the response to these issues is the next step. Identification of potential security issues is not very useful without a known path to protect against those risks. The defense methods become a natural part of the design in this phase of development.

WPA Cracking Proof of Concept Available

WPA passphrases could be cracked—and now the software exists: The folks who wrote tinyPEAP, a firmware replacement for two Linksys router models that has on-board RADIUS authentication using 802.1X plus PEAP, released a WPA cracking tool.

As was noted a year ago, a weakness in shorter and dictionary-word-based passphrases used with Wi-Fi Protected Access render those passphrases capable of being cracked. The WPA Cracker tool is somewhat primitive, requiring that you enter the appropriate data retrieved via a packet sniffer like Ethereal. Once entered, it runs the cracking algorithms.

Remember that to crack WEP, an attacker has to gather many packets, possibly millions, but can then easily crack any key. For WPA, certain shorter or dictionary-based keys are highly crackable because an attacker can monitor a short transaction or force that transaction to occur and then perform the crack far away from the physical site.

The solution to this WPA weakness involves one of three approaches:

Choose a better passphrase: Pick passphrases that aren’t entirely comprised of dictionary words, meaning they need some random nonsense in them. “My dog has fleas”: very bad. “Mdasf;lkjadfklja;dfja;dfja;d”: very good, but hard to type in. Passphrases should be at least 20 characters.

Use randomness to choose a passphrase: A random passphrase of at least 96 bits and preferably 128 bits.



Update: Alert Slashdot readers noted that KisMAC has had a WPA cracking tool built in for several months. KisMAC is a Macintosh-only version of Kismet, a tool for monitoring and cracking wireless networks (for good and evil). Kismet itself lacks this feature. The Mac-only nature of KisMAC has most likely limited the spread of this knowledge.

Two NetworkWorldFusion writers pointed out last month KisMAC’s ability in a great overview of WPA’s weakness and the justification for adopting 802.1X plus WPA.