Webcertiv Security Dashboard

Does your company have money to spend on web security? Chances are you have a (very) limited security budget, and you wouldn’t be alone. In the face of financial hardship, companies looking to cut costs often drop expensive security products and services from their budgets before anything else. Realizing this trend, Webcertiv has launched the Webcertiv Website Security Suite, an affordable, cloud-based security suite providing automated website vulnerability scanning, content integrity verification, and availability and denial-of-service monitoring. Security services can be deployed within a few minutes of creating an account, and the solution requires no hardware or software on the part of the customer. In addition, all security services can be configured, managed, and monitored from a single web-based interface. Best of all, Webcertiv offers a free version of the service for smaller websites. Now, there’s one less excuse for neglecting the security of your website!

Residual heat signatures detected by a thermal imaging camera

At the USENIX Security Symposium in San Francisco, researchers from the University of California at San Diego presented a paper on using thermal imaging to steal ATM PINs. In their paper, entitled Heat of the Moment: Characterizing the Efficacy of Thermal Camera-Based Attacks, Keaton Mowery, Sarah Meiklejohn, and Stefan Savage describe how thermal cameras can be used to detect which keys have been recently pressed on a numeric keypad based on residual heat left from key presses.

During their experiment, the researchers asked 21 volunteers to enter 27 randomly selected PINs on both a brushed-metal keypad and a plastic keypad with rubber keys. Several factors influenced the success of the attack including the keypad material, the participant’s body temperature, and the strength of the button presses. Metal keypads were found to dissipate heat too quickly in most cases for the attack to succeed. However, when using rubber keys (and presumably participants with higher body temperatures and stronger key presses), the cameras could still detect which keys had been pressed with 50% accuracy nearly a minute later. Not only could the keys be determined, but the order in which the keys were pressed based on the strength of the residual heat signatures.

While this attack requires an expensive thermal camera ($17,950 as used in the experiment), a similar and much less sophisticated attack can be used against alarm key pads, garage door openers, and other systems where the same PIN is entered repeatedly and changed infrequently. By noting the amount of wear on the surface of each button and the level of staining from oil and dirt left by fingertips, you can often make out the keys used in the PIN or pass code. Knowing the keys used in a PIN greatly reduces the number of attempts required for successful authentication (for example, a PIN consisting of four digits requires at most 16 attempts, much less than the 10,000 possible combinations of four digits on a 10-digit keypad).

Ask a question now >

We bring up this attack, because it highlights one of the primary weaknesses in many systems – poorly chosen passwords. How do you eliminate this weakness? By preventing users from choosing weak passwords in the first place. This is accomplished through a combination of password policy definition and enforcement within your applications.

Password Policy Definition

A well-defined password policy should take into account password length, complexity, age, and history. When chosen and implemented correctly, these factors greatly reduce the likelihood of an attacker compromising a user’s password.

• Length – The more sensitive the application and the data, the longer the password required. Common password lengths range from six characters for low-to-medium security applications to eight or more characters for high-security applications.
• Complexity – As with password length, more sensitive applications dictate the use of more complex passwords. A complex password consists of a combination of characters from two or more of the following character sets: uppercase letters, lowercase letters, numbers, and special characters (e.g. -_@$). Generally, you will want to require characters from three of more character sets for high-security applications. Regardless of the application, you should still require characters from at least two character sets.
• Age – Password age determines how long a user is allowed to use a password. As a general rule of thumb, you should require users to change passwords every 180 days for low-to-medium security applications and every 90 days for application requiring a higher level of security.
• History – Users should not be allowed to reuse their passwords once they have expired. Doing so increases the likelihood that an attacker will discover a password. To avoid password reuse, previously used passwords should be placed in a password history. The length of the password history depends on the sensitivity of the application, but typical lengths range from 3 to 10+ passwords.

Password Policy Enforcement

In addition to defining a password policy, your operating systems and applications must enforce the policy for it to be effective. Here are some general tips on password policy enforcement:

• Never rely on users to choose strong passwords; enforce proper password policy within your applications. When a user selects a password, check for appropriate length and complexity and ensure that the password does not appear in the user’s password history.
• Even when requiring complex passwords, check for weak character combinations (e.g. abc123, 123abc, Abc123, password1, password2, password3, password123, Password1, Password2, Password3, Password123, etc.). Prompt the user to select a new password if he or she has chosen a weak combination.
• Store the last date that the user changed his or her password, and compare this date to the maximum allowable password age each time the user logs in. If the password has expired, prompt the user to change it.
• Enforce account lockouts following a predetermined number of failed login attempts. Account lockouts help to discourage brute force password guessing attacks. A popular value is five failed login attempts. Anything shorter and you risk locking out legitimate users who are having difficulty typing in their passwords.

User Awareness Training

Regardless of your password policy and how well it is enforced by your applications, there is always the risk of users disclosing their passwords to intruders. Here are a list of precautionary guidelines to share with your users:

• Avoid writing down your password (especially on a sticky note near your computer).
• Don’t share your passwords with others.
• Unless encrypted, don’t transmit a password in email.
• Avoid re-using passwords across multiple applications; ideally, each application should use a separate password.
• Lock or log off your computer when you leave your desk.
• Consider using a password management utility (i.e. passwords safe); a password safe requires a user to remember a “master” password to unlock an encrypted archive of usernames and passwords.

These guidelines are useful, but difficult to enforce. Remember that users are more likely to follow guidelines when they don’t interfere with day-to-day activities. Here are some helpful hints for administrators:

• Unless dictated by the security of the application, don’t require passwords longer than eight characters.
• Don’t require passwords to have characters from more than two or three character sets (e.g. uppercase, lowercase, numbers, and special characters).
• Don’t require users to change their passwords more frequently than once every 90 days.

When Passwords Aren’t Enough

When relying on passwords alone for authentication, there’s little you can do to protect yourself against a user willingly or unknowingly providing his or her password to a stranger. This becomes an ever increasing threat as phishing attacks become more sophisticated. If the sensitivity of your data warrants additional protection, consider multi-factor authentication. Multi-factor authentication requires two or more pieces of information to authenticate a user. The most common forms of multi-factor authentication involve a password or PIN combined with either a token (something you have) or biometrics (something you are). Here are some examples of common two-factor authentication mechanisms:

• Time synchronous tokens
• USB tokens
• Smart cards
• Mobile phones
• Magnetic swipe cards
• Proximity (wireless) tokens
• Fingerprint scanners

1. File  metadata – Files created by desktop applications often include metadata that describes the file and the environment in which it was created. The metadata can include usernames, network paths, software versions, and more. Using a metadata extraction utility, an attacker can build a list of usernames from the files stored on your website. For more information, check out our recent blog post on metadata extraction - Metadata Extraction – Is Your Website Leaking Information?
   
2. User home directories – Many web servers, such as Apache, can be configured to allow personal web pages within user home directories. To access a user’s personal web page, you would enter the corresponding username preceded by a tilde (for example, http://www.domain.com/~asmith/ for the username asmith). When requesting a home directory, the web server will likely respond in one of four ways: 1) with the user’s personal page, 2) with a directory listing containing the contents of the user’s home/web directory, 3) with an HTTP 403 Forbidden, or 4) with an HTTP 404 Not Found. The presence of a personal web page, directory listing, or HTTP 403 Forbidden response indicates a valid username.
3. Email addresses – Spammers use automated applications known as spambots to scour websites for email addresses. An attacker can use this same technique to identify possible usernames. This is especially true when the email addresses contain network login IDs. Even when they do not contain login IDs, it may be possible for an attacker to guess the username format given a list of first names, last names, and/or initials.
4. Employee directories – Like email addresses, employee contact directories provide ample information for an attacker to begin building a list of usernames. The process is further simplified when the directory contains email addresses that begin with network login IDs.
5. Authentication status messages – Attackers often use authentication status messages to enumerate login IDs. Consider the following example – when entering a non-existent username, an application responds with the message “Invalid username”. When entering a valid username with an incorrect password, the application responds with the message “Invalid password”. Using a brute force utility, an attacker could identify valid accounts by submitting possible usernames and examining the contents of the web server responses. Even a difference of a single byte in a web server response is enough for an attacker to distinguish between valid and invalid login IDs.
6. Password reset pages – Web applications often include password reset pages that allow users to reset a forgotten password. These pages commonly ask for a username and then prompt the user with a list of challenge questions. An attacker can identify valid usernames by looking for web server responses containing challenge questions.
7. Application error messages – Web and application servers sometimes return error messages containing server-side file paths. On Unix/Linux-based systems, the file paths can contain user home directories. Most often, the name of the home directory corresponds with a username on the web server.
8. SQL injection – In a SQL injection attack, an intruder inserts malicious strings into web application input fields in an attempt to manipulate the SQL queries performed by the application. The ultimate goal of such an attack is to gain access to information stored in a backend database. When the malicious input is not removed (or escaped) prior to use, it may be possible for an attacker to retrieve usernames and passwords from the database.

Bear in mind that this is not an exhaustive list, and always be on the lookout for sources of information leakage on your website.

Let’s start with a scenario. Like all good security administrators, you have installed a firewall between your internal network and the Internet, and you’ve configured the firewall to allow only those services required by your employees, customers, and partners. One day, you notice an unusually large amount of traffic originating from a desktop on your internal network to a host on the Internet. You inquire with the user of the computer, but he knows nothing about what’s going on. Fearing that the computer has been compromised, you removing it from the network. You later hear about a large, distributed denial of services (DDoS) attack against a high-profile U.S. government agency. After further inspection of your firewall logs, you realize that your host was likely involved in the attack.

When setting up your firewall, you configured the firewall to block incoming connections to all hosts except those in your DMZ. For added security, you explicitly blocked all outbound access from your internal network to the Internet, and enabled only those services required for day-to-day operations. So how was the desktop compromised? Here’s a likely scenario – using a phishing email sent to a personal webmail account, Joe H. Acker, a skilled cyber criminal, tricked an employee within your organization into clicking on a malicious link to a drive-by malware website. A script on the website instructed the employee’s web browser to download and execute a small application that exploited a newly discovered vulnerability in the desktop operating system. The malware then “phoned home” to a web server on the Internet, and was giving instructions to launch a denial of service (DoS) attack. All of this occurred over TCP ports 80 and 443, the network ports assigned to the Hypertext Transfer Protocol (HTTP) and Secure Hypertext Transfer Protocol (HTTPS).

The attack succeeded in part because your firewall allows outbound web requests. Attackers know that most organizations allow internal hosts to make outbound HTTP and HTTPS connections, and they have devised methods for communicating with internal hosts using these protocols. This problem isn’t limited to HTTP/HTTPS either. Hackers have been known to leverage other common ports and protocols, such as DNS (TCP and UDP port 53) and ICMP, to communicate through firewalls. (Note: When encapsulating one protocol within another to bypass firewall restrictions, the process is known as protocol tunneling.)

Now you’re probably saying to yourself, “Wait a minute, I can’t block access to the Web. My users require web access to conduct business.” For most companies completely blocking web traffic is not an option, so what can you do to protect yourself? Here’s a list of products that can help prevent and mitigate attacks over HTTP and HTTPS:

• Desktop firewalls – Possibly the most effective tool for blocking unwanted communication, desktop firewalls can block outbound connection attempts by malicious software. However, if you provide your users with administrative access to desktops or servers, they can easily bypass the desktop firewall restrictions.
  
• Secure web gateways – A secure web gateway protects users from web-based threats by intercepting and inspecting web traffic at the application layer to identify and block malicious activity. Most secure web gateways also block access to known malware websites. In addition, secure web gateways provide for more centralized control and enforcement of your Internet security policy.
• Intrusion prevention systems (IPSes) – Similar in operation to secure web gateways, intrusion prevention devices inspect and block malicious traffic. They typically provide a broader range of protection against network-based threats, but with less specific focus on web-borne threats. In addition, IPSes can detect abuses of non-web protocols, such as DNS tunneling.
• Data loss prevention (DLP) appliances – The primary goal of a DLP appliance is to detect and prevent the leakage of confidential information from your network, particularly over commonly used communication channels, such as web, email, and online chat programs. If an attacker manages to compromise a host within your organization, a DLP appliance may prevent the attacker from transmitting sensitive data out of your network.

Each of these options has its advantages and disadvantages, and a complete solution will likely incorporate more than one product. The number, type, and placement of products will depend on your network environment and communication needs.

As information security professionals, we invest considerable time, effort, and money into staying just one step behind crackers and cyber criminals (yes, you read that correctly, one step behind). No sooner do we implement a cool new security technology to combat an existing threat than the hacker community devises a new type of attack. Keeping up with the growing list of possible threats and attack vectors is a daunting task. It’s a never-ending battle that requires vigilance, insight, and persistence. To keep you abreast of existing and emerging security threats and technologies, we’re launching SML Enterprise Security Tips – a collection of practical tips, tricks, and security insight for enterprise security administrators, architects, developers, and managers. So, stay tuned!

The Secure Mind Labs Team

“My web server was tested in our last network vulnerability assessment. Do I need a separate web application security assessment?”

We get asked this question often. The (not so) simple answer is… it depends. Network vulnerability assessments typically identify vulnerabilities in the host operating system and web server software. Web application security assessments, on the other hand, identify coding and logic flaws within the security framework of web applications. A comprehensive web application testing methodology takes into account user roles, business logic, and application context – three things that automated vulnerability scanners don’t do well. Consequently, your network vulnerability assessment probably won’t provide much feedback in these areas.

In short, the more complex and interactive the web application and the more sensitive the data managed by the application, the more likely you are to need a dedicated web application security assessment. Ask yourself the following questions:

• Does my website host dynamic content?
• Does my web application require user authentication?
• Does my web application support multiple user roles with different access levels?
• Can visitors to my website create accounts and log into my web application?
• Are users allowed to post content on my website (e.g. forums, member pages, etc)?
• Does my web application operate on sensitive or confidential data?
• Does my web application display or provide access to confidential information?
• Does my web application use custom-developed software components?
• Have I made any updates to my web application since my last assessment (in the event that you’ve already had a web application security assessment performed)?

The more questions you can answer with a “yes”, the more you’ll benefit from a web application security assessment. If your application involves financial data or transactions, medical records, student records, or other personally identifiable information, a separate web application security assessment may be required to satisfy legislative and industry requirements (PCI, HIPAA, FERPA, etc).

You should also look beyond the login page when assessing the strength of your web application. Software development teams often focus on the security of externally-facing components (such as login pages) while overlooking security within their applications. Using legitimate or compromised user accounts, attackers frequently exploit internal vulnerabilities as was evidenced by the recent attack on the Citigroup website (http://www.nytimes.com/2011/06/14/technology/14security.html?_r=2). This is another case where a methodical web application security assessments (along with tighter change control management processes) would likely have prevented such an attack.

Keep in mind that just because your application doesn’t operate on sensitive user data, that doesn’t mean that you aren’t at risk. Malicious users leverage vulnerable websites and web applications to launch phishing attacks and to distribute malware. Tolerating such activity can land your website on Internet blacklists and bring you unwanted publicity. Performing a web application security assessment now could save you considerable time and money down the road.

Files created by many desktop applications contain detailed information that describes each file. (To view the information, try right-clicking on a Word document or PDF and selecting Properties.) This information is called metadata, and attackers use this information to uncover details about the internals of your organization. Here are some of the types of information that can be found in file metadata:

• file owner
• author
• local or network file paths
• name of the computer on which the file was created or stored
• name of user who last saved the file
• program that generated the file

One of the most popular tools for extracting and analyzing metadata is FOCA. FOCA locates vulnerable files using Internet search engines. It then downloads the files, analyzes the file metadata, and builds a catalog of user names, email addresses, operating systems, installed applications, network shares, and printers.

FOCA Metadata Extraction Utility

When performing any website security assessment, you should consider the metadata included within the files on your website. This information can reveal a great deal about your organization (e.g. outdated software, anti-virus type and version, user names for remote access, etc).  You can bet that attackers will be doing the same!

You can download the latest version of FOCA by visiting http://www.informatica64.com/DownloadFOCA/.