Saturday, August 25, 2012

Social Networking Sites


What is a social networking site?

A social networking site (SNS) is a web-based service that allows communities of people to share common
interests and/or experiences. Rather than using direct point-to-point communication to stay in touch (e.g., face-to-face, phone, text/video messages), SNSs allow users to publish information that can be read later by other users (a one-to-many form of communication) and follow their friends’ postings and provide comments.
SNSs provide innovative methods for interacting with friends through third-party applications, such as simple games (tic-tac-toe, paper-rock-scissors), interactive maps to show places visited across the world, and quiz/trivia games which allow for score comparison with others. Many SNSs also allow users to logon from
mobile devices that have web browser access to the Internet, allowing them to check and update their accounts from virtually any location with a Wi-Fi or cellular signal.

What are the security concerns?

OPSEC – SNSs promote “social behavior” and encourage users to share information and inherently trust the
information from those they are connected to within the SNS. Once information is posted or uploaded onto an SNS, it should no longer be considered private. Even if the SNS has strong privacy settings, that privacy is completely dependent on the security of the web application. On some SNSs, third-party add-ons have elevated privileges, giving them access to additional private information such as home addresses or birthdays (Mary Landesman, “Cyber Thieves Target Social Sites,” BBC News Online). Savvy attackers may also aggregate information from multiple sites to gain access to private information (e.g., online banking records, email). For example, personal information posted to an SNS (e.g., birthday, pet’s name) could be used to compromise security credentials (e.g., password, pin, security questions) for that site or other sites, giving an attacker access to private information.
Cross-Site Scripting (XSS) – These attacks are a type of code injection, generally in the form of a browser-side script (OWASP, Cross-Site Scripting). Many SNSs allow users to post comments and messages in plaintext,
HTML, or active content (e.g., JavaScript, Flash). If these posts contain malicious content, a user’s web browser could be forced to perform a variety of unintended actions such as downloading malware, surfing to a malicious website, or even causing a Denial of Service (DoS) on the user’s network.
Impersonation – Impersonation of a friend or colleague can be used to trick SNS users into providing private
information or downloading malicious third-party applications or content. In most cases, SNSs perform only a basic check, such as email validation, to confirm a user’s identity.

Malicious Content – SNSs allow users to share a variety of multimedia content, from images to video clips to documents. This advanced content has the potential to contain malicious code, which under the correct circumstances may cause the user’s browser to download malware or perform other unintended actions. An example of how these security concerns can be exploited is detailed in the following: John Smith has a profile on CoolSNS.com. Users can find John by searching, but his profile information is visible only to those authorized by him. He receives a connection request from Sally Jones, and because he recognizes her name from a prior technology conference, he accepts her request. The “Accept” means that John has authorized Sally – or rather, anyone logging in from or impersonating Sally’s account – to view information posted on his profile. A day or so later, Sally sends John a link to a third-party application. Thinking “this is from Sally so I can trust it,” John adds the application to his account. Immediately, a popup displays saying “This application requires an update of Endure Media Player. Please click ‘OK’ to run ‘endure_mp.exe’ for the update.” Trusting Sally, and wanting to experience this application in its entirety, John clicks “OK.” By clicking “OK,” John unwittingly downloads malware, which not only infects his local computer, but also spreads throughout his entire organization’s network causing loss of data and productivity.


What should I keep in mind when using SNSs?

Although quite advanced, social networking sites are simply websites. Safe web browsing practices and OPSEC awareness are the best mitigation strategies for protecting your information. Below is a list of technical and behavioral best practices that can be implemented to mitigate the risks of using SNSs.

Technical Best Practices

• Ensure your operating system and web browser are up-to-date with the latest patches (System and Network Analysis Center IAD, “Defense Against Drive-by Downloads,” NSA/CSS).
• Maintain a blacklist of blocked sites for your network.
• Update your virus scanners with the latest definitions and patches, and scan often.
• Do not browse the Internet from privileged accounts such as root or Administrator.
• Enable Data Execution Prevention (DEP) in the OS to prevent buffer overflow attacks (System and Network Analysis Center IAD, “Data Execution Protection,” NSA/CSS).
• Install an application firewall or Host Intrusion Prevention System (HIPS) and enable whitelisting.
• Apply Software Restriction Policies (SRP) on machines running Microsoft Windows platforms (XP/Server 2003 and newer). SRP keeps a whitelist of allowed executables, preventing the installation of malicious downloads.

Behavioral Best Practices

• Perform a risk assessment before posting information about you or your organization. Never post any sensitive information, and post information as if privacy or filtering settings do not exist within the site’s functionality. Sensitive information (e.g., address, phone number) should be left off all social networking sites.
• Before accepting a friend/connection request, confirm with them either verbally or face-to-face. This ensures that the involved accounts are neither compromised nor impersonated.
• Be selective of which third-party applications to add to your profile. There is no guarantee that thirdparty applications have been reviewed or officially approved by the parent SNS. These applications could contain malicious code attempting to exploit your account and the site at large.

Tuesday, August 21, 2012

Data Execution Prevention (DEP)


Computer attackers commonly use buffer overflow exploits to gain access to computer systems. Many of these malicious code exploits can be prevented with Data Execution Prevention (DEP), a security feature available in modern operating systems. DEP provides protection for all memory that is not specifically marked as executable code. This guide discusses how to configure and enable DEP.

Enable Hardware Support for DEP

Most personal computers sold today include hardware support for DEP. Hardware support can be enabled or disabled by a BIOS setting. It is recommended that hardware support for DEP always be enabled. BIOS settings vary depending on the manufacturer, but the DEP option can usually be found in the Security section. When replacing older systems it is recommended to purchase systems with hardware support for DEP.
Intel® refers to its hardware support as Execute Disable Bit (XD), and AMD™ refers to it as the No-Execute Bit (NX).

Windows® DEP Settings

On Microsoft® Windows XP SP2, Windows Server 2003™ SP1, and Windows Vista™, DEP operates in one of four possible settings: AlwaysOn, OptOut, OptIn, and AlwaysOff. It is highly recommended to configure DEP to operate in either the AlwaysOn or OptOut setting.
AlwaysOn protects all applications without exception. This is the preferred setting but is not practical where DEP-incompatible applications are necessary.
OptOut is the next best option and is the default setting for servers such as Windows Server 2003 SP1. OptOut applies DEP protection to all specified in an OptOut list.
The final two settings are not recommended. OptIn is the default setting on clients such as Windows XP SP2 and Windows Vista and protects only core Windows components. AlwaysOff disables DEP.
The address space layout randomization feature in Windows Vista provides further protection and compliments DEP powerfully.

Enable DEP on Windows XP SP2 and Windows Server 2003 SP1

DEP can be enabled by modifying the system’s boot.ini file or through the Control Panel. The Control Panel cannot be used to configure the AlwaysOn or AlwaysOff setting. Both methods require Administrator privilege on the system.
To enable DEP through the boot.ini file, add one of the following flags to the end of each line in the [operating systems] section:

/noexecute=AlwaysOn
/noexecute=OptOut

Save the changes and reboot the system. These changes can also be made using the bootcfg.exe tool in Windows XP Professional.
To configure DEP using the Control Panel, launch the System Properties applet from the Control Panel. Select the Advanced tab, and then click on the Settings button in the Performance section. Click the DEP tab in the Performance Options window (See Figure 1). To select the OptOut setting, check the box labeled “Turn on DEP for all programs and services except those I select.” The system must be rebooted before DEP protection is activated.
Figure 1: DEP Configuration Window


Enable DEP on Windows Vista

Windows Vista does not use a boot.ini file. DEP can be enabled by modifying the system’s boot configuration database (BCD). To do this, execute either of the following commands from a command window with Administrator privilege, and then reboot the machine.

bcdedit /set nx AlwaysOn
bcdedit /set nx OptOut

DEP can also be enabled in the System and Maintenance section of the Control Panel. Click System 􀃆 Advanced System Settings 􀃆 Advanced tab 􀃆 click Settings in the Performance section 􀃆 DEP tab (See Figure 1). To select the OptOut setting, check the box labeled “Turn on DEP for all programs and services except those I select.” The system must be rebooted before DEP protection is activated.

Excluding Windows Applications from DEP Protection

Some legacy applications may not run on a DEP-protected system. All enterprise applications should be tested for DEP compatibility. If the vendor cannot supply an updated DEP-compatible version, the product can be excluded from DEP protection when the OptOut setting is selected.
Microsoft’s free Application Compatibility Toolkit can be used to create a Custom Compatibility Database file (*.sdb) to omit a program from DEP protection. The file can be easily deployed across an enterprise. 64-bit applications are protected by DEP by default and cannot be exempted.
Red Hat® Linux/Fedora™ Support
Red Hat Enterprise Linux™ version 3 update 3 and later, and Fedora Core 1 and later, provide DEP and address space layout randomization as part of the ExecShield feature. It is enabled by default. To verify, issue:

sysctl kernel.exec-shield

The expected output is 1. If the output is not 1, investigate /etc/sysctl.conf and startup scripts, to re-enable ExecShield. ExecShield provides hardware-enforced DEP even on older systems by using the code segment limit on all x86 processors. For further protection, install the kernel-PAE package to make use of the processor’s XD or NX feature.

Sun™ Solaris™ Support

Sun Solaris supports a non-executable stack on both SPARC® and XD/NX-capable x86 systems. To ensure this feature is enabled, add the following line to /etc/system:

set noexec_user_stack=1

Apple® Mac OS® X Support

Mac OS X on Intel processors supports DEP through the processor’s XD bit. It is enabled by default. To verify, issue:

sysctl kern.nx