Security Optimization Strategies

Security Optimization Strategies in the Workplace is about Protecting Your Company or Business Against Vulnerabilities, Worms, Viruses and Spam Attacks with Common Sense Business Practices.

Security Optimization

Tired of worms and viruses affecting your network or system while you still investing in security solutions? Did you know that many security risks can be minimized or avoided altogether with common sense practices? This article describes important security optimization strategies for

• email, network and firewall administrators interested in minimizing security risks
• human resource, security and IT departments needing coordinated security programs
• universities, small businesses and large corporations exposed to security incidents

These strategies and remedies can be implemented in coordination with human resources, IT and security departments. In some cases a tradeoff between accessibility, performance and practicability is required. After all, optimization is the art of finding a happy medium.

On Mass-Mailing Worms, Viruses and Email

Most mass-mailing viruses and worms are transmited by grabbing email addresses from online documents and databases, or once hosted in a machine, by collecting email addresses from email client applications. Unlike viruses, worms may require limited user interaction or no user interaction at all. Often these 'creatures' arrive to the email client with their own SMTP (Simple Mail Transfer Protocol) engine, grabs e-mail addresses from files stored on compromised computers and resend themselves to identified email addresses. Some may come with or without subject lines and may include malicious links or attachments. Once inside a system, the malicious program can set up a backdoor or allow remote code execution, install programs, view or change information, create accounts with full privileges or act as its author pleases.

A recent breed of mass-mailing worms comes in the form of 'pointers'. Users are lured by e-mail messages, which do not contain virus-infected file attachments but mere links. The idea is to point users to apparently trusted urls. The worms often use a combination of phishing techniques, IP obfuscation (spoofing) and deceiving link practices to trick users into following links or downloading malicious programs. Some links may direct users to pornographic Web sites. In addition to stealing e-mail addresses for the purpose of spreading itself, a pointer may forward the addresses found on compromised systems to another e-mail addresses, which could be harvested by spammers.

Email Forms and Header Injections

If you use forms to allow users to send email, you must know that hackers can use it to inject headers and sent email to whoever they want. Thus, your site can be turned into an accessory for malicious activities.

To learn about this risk and some workrounds, visit the PHP.net site.

Posting Emails: The Killer Resource

Email has been called the Web killer application. In the under world of hackers, posting emails is a killer resource since often the chain of events that lead to security attacks are triggered when a malicious program gathers email addresses. Thus, common sense dictates that a network administrator or webmaster should not facilitate email addresses to untrusted sources. Saddly to say, many government agencies, companies, schools and universities facilitate email addresses without protecting these. This is a symptomatic condition on the Web.

Unfortunately, many webmasters and network administrators are not willing to change old habits or recognize that this is a terrible mistake --until it is too late. As expected, when mass-mailing worms or viruses strike, these exposed environments -as those in upper level management positions- feel the pain first. The dollar value associated to the lost of productivity, impairment of daily operations, waste of man-hours and misuse of human resources can be high.

One way of minimizing the risks associated to posting email addresses consists in providing official email guidelines. The National Research Council, Canada, has devised an interesting approach that human resource departments might want to replicate.

Staff documents have an active link that reads "Email" or "Contacts". Clicking the link sends users to an email guideline page. This pages has the following instructions:

In order to send an e-mail to this NRC-IIT staff member, please use the following general formula:

FirstName.LastName@nrc-cnrc.gc.ca

Additional Guidelines
Hyphenated names (e.g. Jean-Guy Beauchamp)
- include the hyphen with no spaces on either side
(e.g. Jean-Guy.Beauchamp@nrc-cnrc.gc.ca)

Two-part names (e.g. Maria De Villiers)
- remove any space between names
(e.g. Maria.DeVilliers@nrc-cnrc.gc.ca)

Names with accents (e.g. Stéphane Biron)
- remove accent (e.g. Stephane.Biron@nrc-cnrc.gc.ca)

Please note that the e-mail addresses are not case-sensitive.

Quite clever. Note that this requires of human input.

Security Strategies for Webmasters

Mass-mailing worms work also as email bots. Email bots are programs designed for the sole purpose of collecting email addresses from web pages, databases, discussion groups, guestbooks, address books, etc. They work by matching text patterns (the email address) with coded regular expressions. Many spammers and email marketers feed their databases with such programs. Whenever possible, webmasters should minimize or avoid altogether the publishing of employees' email addresses in web sites. Facilitating their email addresses just simplifies the work of spammers and worms.

What if email addresses must be published? In this case a savvy webmaster can resource to any of the following risk-minimization strategies. These strategies allow the rendering of email addresses while making the addresses practically invisible to most email bots.

1. Display email addresses as preloaded image files. This strategy works well with most email bots. However, since the field of visual recognition searches is evolving at a fast pace, the technique may not work in the near future. Since the web browser must request and download the image files, this strategy affects speed of execution and is not recommended for sites that need to display large number of email accounts. Some webmasters resource to text-to-pdf document conversions, but this technique protects nothing since pdf-to-text converters are available elsewhere.
2. Encode email addresses using Unicode entities, character by character. Unicode tables and text-to-Unicode encoders are available elsewhere. This strategy may not work with email bots that can decode Unicode entities before processing regular expressions. Fortunately, not all email bots are that smart.
3. Encode email addresses using hexadecimal notation, character by character. This strategy may not work with email bots programed to make hexadecimal-to-decimal conversions before processing regular expressions. Fortunately, not all email bots are programed to do this.
4. Encrypt email addresses using a combination of scripts and public key encryption (e.g., JavaScript encryption). This allows the rendering of email addresses provided that the browser can interpret the key. Fortunately, IE and NS browsers can interpret JavaScript encryption --JavaScript must be enabled. This strategy stops most email bots and preying eyes. However, keep in mind that cryptographic geniuses may have no problem decoding encrypted addresses.

The masking of email addresses is just one of many security layers available to webmasters and network administrators. The next paragraphs discuss other security layers.

Security Strategies for Human Resource Departments

Human resource departments should educate employees on the proper use of email and online resources in the workplace. The goal here is to train employees on common sense security practices. The following strategies can be implemented in coordination with IT and security departments.

When emailing a message to multiple recipients, instruct users not to place multiple addresses in the carbon copy or "Cc:" field. This broadcasts all email addresses to all recipients. While the "Cc:" field could be used in some workplace settings (e.g., to circulate a message within a department, office or intranet) the indiscriminate use of the "Cc:" field can raise privacy issues and could expose senders, universities and companies to lawsuits, especially if emails are sent to recipients outside the workplace. Rather, instruct users to use the blind carbon copy or "Bc:" field. This allows users to send messages to multiple recipients without broadcasting their accounts. To use the "Bc:" field, the email client application must be configured. For instance, if your email client is Outlook Express, do this

1. Create an email window.
2. Select View > All Headers.
3. Write one and only one email address in the "To:" field.
4. Write or paste as many addresses as needed in the "Bcc:" field.
5. Send email.

Outlook should retain these settings. These days of spammers and worms, the "Cc:" field is one of the first things spammers check when collecting email addresses from incoming emails. Why simplify their work?

Instruct users to delete right away and never respond to or follow links provided by unknown or untrusted sources such as

1. spam email
2. unsolicited newsletters
3. chain letters
4. contests
5. bank, credit card, debit repair offers
6. obscure link exchange programs
7. untrusted search engines site submission offers

Instruct users to delete right away and never respond to or follow links provided by unknown or untrusted resources often present in

1. unsolicited subscriptions - don't even reply by clicking "Unsuscribe" or "Cancel Subscription"
2. unsolicited polls and questionaries
3. chat rooms (IRC, Web-based cyber rooms)
4. discussion forums and guestbooks
5. unsolicited webcast sessions
6. pop up/under windows

Instruct users to be wary of signing for or downloading freeware or shareware from unknown or untrusted sources. This includes

1. free email subscriptions --all kind of email subscriptions
2. games --all kind of games and online toys
3. free software; especially, management tools, system "solutions" and add-on freebies
4. free audiovisual add-ons such as "skins", screensavers, pictures, videos and audio files
5. unsolicited "antivirus" and "antispyware" software

Schools, universities and companies may elect to limiting or denying privileges to repetitive offenders. After all, most of the above activities should not be conducted or tolerated in a workplace or an academic setting. The bottom line: a human resource department may want to handle the behavior of online employees as a security layer.

Security Strategies for Office Managers

Security optimization strategies for office administrators are easy to implement. However, one-size-fits-all solutions are not possible. A strategy must be tailored around the needs of the workplace. While an email administrator don't want to affect daily operations or employees performance he or she should ponder the pro's and con's of

1. disabling support for HTML e-mail. This can be done at the client level, by configuring individual machines or by using other means at the server level (recommended). This limits exposure to HTML-based and link-based security risks but impairs users from accessing valid HTML content.
2. configuring all client software to be run as a non-privileged user with minimal access rights. All non-administrative tasks such as retrieving, saving, reading and moving e-mail should be performed as an unprivileged user with minimal access rights.
3. training users on the proper constructions of message rules. If using Outlook Express, such rules can be constructed by pointing the browser to Tools > Message Rules > Mail and clicking a tab task.
4. at the server level, using an email management program (e.g., IMail and similar programs). These programs can be configured to execute email tasks such as delete, bounce, forward, reply, etc and according to predefined message rules for the "To", "Subject", "From", "Body" fields. Many commercial ISPs already include similar email management tools in their service packages. Properly configured, these managers stop considerable amount of spam email before reaching individual email accounts.

Note that these strategies can be viewed as security layers working at the 'gateway level'.

Security Strategies for Network Administrators

Network administrations may want to consider the following measures.

1. By definition, an intranet is an isolated architecture. Never connect (physically or through links) an intranet to a web site, database or to a network that can be accessed online. This is a serious mistake. An architecture that anyone can access through a browser no longer is an intranet. Some administrators resource to such "solutions" in order to save costs. Compromising security with temporary, sloppy or low cost solutions may result costly in the long run. Unfortunately, we know of some universities and companies in Puerto Rico that have done or are still doing this terrible mistake.
2. Never use a server connected to the Internet to store sensitive information or intranet resources. Deep breath crawlers and similar robot programs can and will crawl all links and documents found in the server while traversing the Web. Don't assume that all crawlers follow the Robots Exclusion Protocol. Often one can find such documents by properly querying search engines or with a browser, by carefully crafting url paths.
3. Use redundant architectures with intranets reserved for research and development. Again, never connect the intranet to online resources or to other intranets.
4. Whenever possible, do not incorporate unsecured servers within intranets reserved for research and development.
5. Turn off, unplug and disconnect the cable or line modem that connects unused computers to the Internet, especially when users are on vacation or during long weekends. Some administrator go to the extreme of doing this on a regular basis and overnight. Asides saving operational costs, this common sense task protects the unit from being turned into a zombie --a machine that's been taken over and directed to attack other computer systems. Such attacks can be launched without the computer user doing anything.

Security Strategies for Firewall Specialists

Firewall administrators may want to check the following references (1 - 3)

1. use the Intruder Detection Checklist available at CERT.org
2. sign up for The National Cyber Alert System available at US-CERT.gov
3. get a copy of The ISAlliance's Common Sense Guide for Senior Managers available from the ISAlliance.org site
4. ponder the pro's and con's of disabling support for Java, JavaScript and ActiveX components
5. configure a firewall to do multitasks such as intrusion autoblock followed by autotracing (traceroute, ping, etc.). An administrator may also want to use a 'looking glass' tool to check for other environmental parameters of the corresponding ip.
6. keep updated all Trusted and Restricted Zones.

For companies that cannot afford an expensive firewall, a software-based personal firewall of the combo type may be an option. These products come with antispam, antivirus or antispyware capabilities and are designed to simplify many administrative tasks.

Last but not least, a dedicated administrator may want to learn how to interpret email source codes (email headers). These are pieces of information that come with every single email. An email source code often reveals the true identity of the sender and type of transmission technology used (masked/unmasked email and ip addresses, transmission paths, type of applications, etc).

To view a source code, do this (Outlook Express).

1. Open Outlook Express and right-click an email file.
2. Select 'Properties' and click 'Details' tab.
3. Click 'Message Source' button.
4. If you wish to copy the source, right-click the active window and chose 'Select All'. Right-click again the active window and select 'Copy'.

Interpreting email source code is important. If a dubious email or spammer strikes, the administrator can look at the source, identify any masked/unmasked email or ip address(es) and place them in the blocked or restricted zones of the firewall. He/she may want to do a trace route right away.

Security Strategies for Searchers, Testers, and Hack Profilers

Everyone in an administrative position should know that poor usage of keyword terms in documents can be targeted by search engine users. Such users not only can have a legit interest but can also be hackers looking for vital information or for specific targets.

The following search commands in Google often provide hackers with invaluable information. A detailed description is given in Google Hacking: Ten Simple Security Searches That Work and in the book Google Hacking for Penetration Testers, by Johnny Long, Ed Skoudis; Published by Syngress; ISBN: 1931836361; Published: June 2001; Copyright; Pages: 528.

I have added to the list other queries I tested for an intelligence project.

1. Site - provides all sort of information about a site.
2. intitle:index.of - Universal search for directory listing, especially Apache-style directory listings.
3. error | warning - Error messages are revealing in just about every context. Warning text in search results can provide important insight into the behind-the-scenes code used by a target.
4. login | logon - Locates login portals fairly effectively and can be used to harvest usernames and troubleshooting procedures.
5. username | userid | employee.ID | "your username is" - The most generic searches for username harvesting. The context around these words can reveal procedural information an attacker can use in later offensive action.
6. password | passcode | "your password is" - This query reflects common uses of the word password and can reveal documents describing login procedures, password change procedures, and clues about password policies in use on the target.
7. admin | administrator - This query can be used to reveal procedural information ("contact your administrator") and even admin login portals.
8. -ext:html -ext:htm -ext:shtml -ext:asp -ext:php - This query, when combined with the site operator, gets the most common files out of the way to reveal more interesting documents. It should be modified to reduce other common file types on a target-by-target basis.
9. inurl:temp | inurl:tmp | inurl:backup | inurl:bak - This query locates backup or temporary files and directories.
10. List of Sites - This gives you site community information.
11. intranet | help.desk - This query locates intranet sites (which are often supposed to be protected from the general public) and help desk contact information and procedures.
12. extranet | help.desk - Same as previous query.
13. mailto - This gives you email addresses.
14. phone - This gives you phone information.
15. ssn - This gives you social security numbers information but numbers may not necessarily be active numbers.

Of these searches, in my opinion the most troubling are searches for social security numbers (SSNs). The facilitation through search results of SSNs by search engines, directories, university sites and other sites is a symptomatic problem across the Internet. Clicking on a record from a search engine result pages can direct one to a document with more incidents. If the search engine distributes its search results to web partners, then the number of incidents are multiplied.

This problem is not unique to search engines. Many web properties are at fault: from government agencies and universities to churches, non-profit organizations and financial institutions. Often public documents form city halls, public minutes/sessions, or senate transcripts are found containing SSN, phones, email, physical addresses of citizens. One only need to search in Google or other search engines to find the incidents.

These incidents are mostly due to bad business practices or ignorance. Considering that with a valid SSN other forms of identification can be obtained, this is a problem relevant to law enforcement and homeland security. It is also relevant to inmigration agencies since it can be more evident in states and territories affected by undocumented people and illegal alliens such as California, Arizona, Texas, Florida, New York and Puerto Rico. Stealing SSNs is also an enabling crime since it can lead to identity theft or who knows what sort of terrorist or criminal activites.

Here is an interesting query format I tested back in 2002-3 across all major search engines. Try searches of the form

"SSNd" a + k

Note the quotes in "SSNd". Try "SSN:", "SSN:a", "SSN#a", "SSN: a", "SSN# a" alone or with "k" where

• d = a delimiting character such as ":", "#", "-", ".", a space, etc
• a = up to 1973, a state assigned code. List by states and territories is available at the Social Security Administration site, in books, scripts and elsewhere.
• k = a keyword(s), like court, report, lawsuit, case, divorce, bank, bankruptcy, state, etc.

These type of combinations provide interesting possibilities for both law enforcement, profilers, private eyes and unfortunately, for some with criminal intentions. I strongly recommend university administrators, schools, churches, non-profit organizations, government agencies and companies to never assign and use SSNs for any sort of transaction. And how about the practice of using the last four digits of a social security number? Don't even think about it. With the first three digits (given by states prior to 1973) and the last four one only need to guess the two digits in the middle of a SSN.

For those interested in mining these type of searches, as well as searches involving email headers, Search Engine Watch Forums (SEWF) features my thread Search Security Strategies, in which I provide an in-depth discussion of these type of smart searches and what kind of intelligence you can extract from these. The thread by no means pretends to promote or encourage bad behaviors but to show how many webmasters, web properties and network administrators are unnecessarily exposing sensitive information online, not only from their workplace, but from clients and associates. Hopefully the information covered at SEWF would help others to improve their workplace security with common sense business practices.

Feedback from Readers

1. External CSS Files A reader asked if importing CSS files from other domains represent a security risk. The answer is YES. Secunia has reported a vulnerability where the content of imported CSS (Cascading Style Sheets) from other domains is not properly protected from being read via the "cssText" DHTML property. According to Secunia, "This can be exploited by a malicious web site to disclose parts of the content of certain documents served from another web site (e.g. HTML documents with a certain structure which can be parsed by the internal CSS parser), by loading the document via the "@import" directive and accessing the content of it via JavaScript." Common sense dictates that each time you rely on files placed in third-party servers you are extending an invitation to troubles. Whenever possible disable Active Scripting except for trusted sites. If you have a web designer in your payroll, ask him to do his job and design in-house all CSS files. That's just common sense.
2. Unread Emails A reader asked if emails left unread or unanswered may pose a security risk.
   Most definitely. Recently detected Lovegate.W worm spreads by replying to unread emails in a user's inbox. The worm searches for unread messages in MAPI-compliant E-mail programs, such as Outlook and Outlook Express, and send itself as a reply to any in-bound message. To deceive anti-spam software and message rules (filters), this worm uses subject lines of unread emails as its own subject lines. Pretty clever. Advice: Delete any unread email you think you don't want to read or reply to. Use common sense. Why make room for a risky vector?
3. IRC and Chat Programs A reader asked if IRC and Chat channels can pose a security risk.
   Yes. Many worms search for IRC and chat channels to inflict damage. For example, the recently detected Korgo.B Worm attempts to connect to certain IRC channels to enable remote access. Advice: If you or your employees don't use or need IRC or any instant message application in the workplace, disable (or remove altogether) these gizmos and similar "toys". Why tolerate chit chat activities in the workplace? Remove this vector risk from your business landscape. Large organizations may want to include this in their HR and security policies. Again, use common sense.
4. Banning Blocks of IPs A reader asked how he can ban an entire block of IP addresses used by an email spammer.
   An IP address is a four byte value expressed by converting each byte into a decimal number (0 to 255) and separating the bytes with a period. The first two bytes (Class B) are assigned to large networks, The first three bytes (Class C) are assigned to small networks. The last byte identifies individual computers and by convention (not always) is set to 1 for routers. Thus, if a spammer sends email through several computers connected to the same network, ban his/her network IP. Try this
   
   
   • obtain the sender's IP by looking at the source code (headers) of the email received.
   • write an email message rule to block any email that matches the first three bytes of the sender's IP.
   
   In addition, you may want to configure your firewall to block any IP address within a certain range. For example, if the spammer IP is131.132.59.100, set your firewall to block any IP within the 131.132.59.0 and 131.132.59.255 range. You may want to think about the pro's and con's of using this extreme strategy. ISPs assign to most subscribers temporary -and dynamically generated- IP addresses. Thus, if a spammer sends email through an ISP, you may end banning any legit email sent to you from that ISP. You may want to configure your firewall to accept emails coming from trusted IPs or domain names.
5. Drag-and-drop events A reader asked if a webmaster should disable drag-and-drop event handlers.
   Although this may compromise accessibility, it may be a good idea. It is well known that users can add to the browser favelets (bookmarklets). This is usually done by dragging and dropping into the browser toolbar certain links that contain scripting instructions. Some favelets may point to dynamic urls or code with malicious intentions. Like some "invisible gifs", some favelets have been designed to talk to cookies, acting as "web bugs". Be wary of favelets pointing to executables or to code residing in external servers. Their tasks can be changed at will at the other end.
6. AutoResponders A reader asks if autoresponders (autoreplying programs) pose a security risk.
   In a nutshell, autoresponders flags a person, spammer or worm waiting at the other end that (a) the email sent was received (b) from the email headers, which ip address was used by the autoresponder, when and how, and (c) that the account targeted may be a valid email address.
   
   Thus, an autoreplying program that indiscrimately responds to any email address is a security risk since it cannot discriminate between trusted (co-workers, clients, etc) and untrusted emails (spammers, worms, etc). Such autoresponders are just automatic facilitators of information. Consider the following autoresponse used by an employee while on vacation
   
   "I will be out of the office and on vacation from --/--/-- , returning to the office on --/--/--. If you need to contact me call __________ at extension ______ or call my assistant _____ at extension ______ or call/email me at (cell, home) at ______ or at ____@_____."
   
   What's wrong with this? A lot.
   (a) Note the chunk of information facilitated to a spammer or email bot waiting at the other end.
   (b) The facilitated email/phone accounts can now be targeted.
   (c) Reverse lookups for names and phones could reveal additional information.
   (d) Email headers may reveal the ip address of the unused machine and, if left plugged to the Internet, this machine could be exposed to a zombie attack.
   (e) Last but not least, the fact that an email was replied (by a human or autoresponder) in such manner flags a spammer or bot that the target could be a valid email address, so as the information facilitated.
   
   Thus, common sense dictates that unproperly configured autoresponders are a serious security risk in the workplace. A human resource administrator may want to train employees on the proper setting of autoresponders or even better, handle all autoresponses or preset a standard autoresponse message for all employees. The administrator may want to coordinate this with an email or network administrator. They may elect to fast forward all incoming emails to an alternate employee account.

References

1. Intruder Detection Checklist, CERT.org
2. The National Cyber Alert System, US-CERT.gov
3. Common Sense Guide for Senior Managers, ISAlliance.org

Thank you for using this site.

Status of the Current Document 
  

Copyright © 2006 Mi Islita.com - ▲