January 09, 2014

3.2.18 Client-Side Attacks

Client-side attacks

Because that’s where the money is. – Quote apocryphally attributed to bank robber Willie Sutton when ask why he robbed banks.

People create structures to provide security from attack for their persons and property. As with most security mechanisms, it becomes an “arms race”; the attacker devising increasingly sophisticated measures to penetrate the defense and the defenders improving their security profile to repel the penetration attempts.

Nomadic humans first formed camps as a way leverage resources and protect each other from attacks by marauders and other hostile forces. As the attacks against the camps became more sophisticated, the protections evolved to repel the threat. The camps evolved into forts, forts became castles, castles grow into fortified towns, etc. At each stage, the strength of the fortification becomes a deterrent to the attacker who then cast about for more effective penetration techniques or an easier target.

In computing, the server is the fortified structure created to serve and protect data and services. As the target of attacks, it may be initially vulnerable, however it eventually improves defenses enough that most attackers begin looking for easier targets.

Using a castle analogy, if one cannot breach the castle walls to plunder its resources, the next best thing is to intercept it before it reaches the castle. This is the equivalent of the client-side attack.

As server-side resources, i.e. resources stored on the server, become increasingly difficult to access due to improved processes and security advances, malicious users instead direct their attacks against the less well-defended client devices and applications. I.e. they moved from attacking the server to attacking the client.
An Exaggerated View of Server-Side & Client-Side Security
A client can be a standard web browser such as Internet Explorer or Google Chrome or it can be an embedded browser object in an application such as an email client, media players, e-book reader, etc.

Servers are juicier targets for the malicious user as they contain the data sought by the malicious user and because servers are naturally designed to make information available to users.

Web servers, database servers, mail servers, streaming video servers, etc. all contain data they want to make available to users. The trick is to increase the defenses of the server enough that the strategic value of the data is less than the cost of measures needed to penetrate it.

Servers are improving their defenses, encouraging attackers to turn increasingly to client-side attacks.

Two reasons why client applications are more inviting targets for attackers include:
  • Clients generally undergo less rigorous security testing than server applications
  • Clients are more difficult to patch due to the diverse range of client versions, owners and environments
Executing code at the client, such as by embedding JavaScript in HTML pages, makes dynamic and interesting content possible. An example is the page interactivity possible in Google Maps. However these capabilities add complexity and introduce the potential for security vulnerabilities into the application.

“Cross-site scripting (XSS) is a vulnerability that permits an attacker to inject code (typically HTML or JavaScript) into contents of a website not under the attacker's control. When a victim views such a page, the injected code executes in the victim's browser.”‡

Cross-site scripting or XSS is a type of client-side attack. XSS takes advantage of interactions between the client and server to exploit any resulting vulnerabilities.

What does the “cross-site” in cross-site scripting mean? A good explanation is the one from apache.org, “It was coined earlier on when the problem was less understood, and it stuck.”

Cross-Site Scripting is an attack technique that embeds malicious code into a user’s browser instance. When the malicious code is triggered, it executes on the client-side (i.e. in the user’s browser) and is generally used to add, modify or delete data. The malicious code can be in one of various script languages including Java, JavaScript, VBScript, ActiveX.

When running in the local browser instance, the malicious code the privileges of the user, as such it has the ability to access and modify potentially sensitive local user data. Via XSS a malicious user can take control of the session between the browser and a website, and access sensitive data or redirect the browser to a malicious web site.

Categories of XSS

There are several recognized categories of XSS attacks including: Stored XSS, Reflected XSS, Cross Site Request Forgery (CSRF), Cross-Site Tracing (XST) and DOM-based XSS. In this article we will look at Stored and Reflected XSS.

XSS vulnerability is introduced when a web site accepts input from the client without first validating that the data is “clean”, i.e. in the format it was expecting and also when the web site outputs data to the web client without sanitizing it, i.e. removing or masking any potentially dangerous code.

When an attacker discovers a server that is not validating or sanitizing data, it will send the server malicious data, e.g. by filling out a form with input that is a script instead of simply text. Since the server is not doing input validation, it either incorrectly stores the script in its database where it gets executed by the next user accessing the database or it gets reflected back to the browser.

Stored XSS Attacks – are those where the code to exploit the vulnerability is permanently stored on the target servers (typically in a database) and can be retrieved to create pages sent to any user visiting the site. The victim retrieves the injected script from the server when it requests the stored information.

Forums and blogs that allow the use of HTML and that store information in databases are potentially vulnerable to this form of exploit. Protecting against stored XSS exploits involves input validation and output sanitization, i.e. translating the elements such that it will not be interpreted by the browser as code.

Stored Cross-Site Scripting is also known as Persistent Cross-Site Scripting.

Reflected XSS Attacks – are those where the attack is in the request itself and the vulnerability occurs when data submitted by the client is processed by the server and sent back (reflected) to the browser without first being properly encoded or sanitized. The Reflected XSS attack begins when a victim visits a URL with the embedded malicious script. The malicious URL can be distributed in the form of an email sent by the attacker. An exploit is successful when the:
  • victim loads the malicious code in his/her browser
  • code gets sent to the server listed in the URL
  • server “reflects” the malicious code back to the browser embedded in the response, (such as an error message or search result)
  • browser dutifully renders the malicious code (as it came from a “trusted” web site)
  • malicious code does its work
Step #0 of this exploit is finding a web server that processes raw HTML on input without scrubbing or filtering and on output without encoding or sanitization.

XSS exploits can perform various malicious activities for the attacker, including:
  • steal information in script variables
  • set or read information in cookies
  • send requests to a server as the user
  • redirect to another site
  • modify displayed content
  • send captured data to another site
  • log keystrokes, capture camera data, etc.
Unlike with Stored XSS where the malicious code is persistently stored on the server and activated by any visitor to that page, the Reflected XSS is commonly delivered via phishing attacks or via a compromised web site.

The attacker may attempt to evade detection by encoding portions of the malicious script in hexadecimal characters, making it less like a script and less suspicious.

A Cross-Site Scripting (XSS) vulnerability arises when Web applications take data from users and dynamically include it in Web pages without first properly validating the data.†

Minimizing the vulnerability of Stored and Reflected XSS involves following web good coding practices such as validating, filtering or scrubbing input at the server-side and by sanitizing or encoding output before execution at the browser-side. If input data is not validated, malicious script can be inserted into the page that is sent back to the browser where it runs in a trusted context.


January 06, 2014

3.2.15 Malicious Insider Threat

Malicious insider threat

We have met the enemy and he is us. – Walter Crawford Kelly, Jr.

IT security professionals and laypeople alike are aware of IT security threats posed by external forces such as hackers, malware, denial of service attacks, etc. Systems and policies to mitigate these “outsider” security threats such as firewalls, intrusion detection and prevention systems, antivirus software, etc. are well defined. However these security mitigation efforts are largely ineffective against what several studies have recognized as a significant threat to an organization’s security profile, the malicious insider.

Electronic Crimes most costly or damaging to an organization
Bob Bragdon, VP and publisher, CSO puts it this way “Cyber threats can come from outside and inside the organization. Public awareness has been largely focused on the more sensational successful cyber espionage attacks from nation-states, but the fact is insiders with malicious intent also pose a great security risk.”

Insiders necessarily have legitimate access to internal resources and are familiar with the organization's security controls for protecting them. A malicious insider is a current or former employee, contractor, or business associate who has or has had authorized access to an organization’s resources and has (incidentally or intentionally) misappropriated that access in a way that negatively impacts the confidentiality, integrity and availability of the organization’s resources.

According to research by CERT, the malicious insider is motivated in many cases by revenge and greed and as such his or her activities will include sabotage of computer systems, extortion, theft of Intellectual Property and exposure of private information.

Most Common Insider Cyber Incident
Unintentional exposure of private or sensitive data 34%
Theft of intellectual property (IP) 34%
Theft of other (proprietary) info including customer records, financial records, etc… 31%
Unauthorized access to/ use of information, systems or networks 30%
Source: 2013 US State of Cybercrime Survey

Malicious insider threats are difficult to defend against since the insider has intimate knowledge of security controls and methods bypass them. The scope of the impact of malicious insider threats may be underreported and likely underappreciated. The following table from a 2006 survey highlights how over 400 organizations handled both insider and outsider threats: ‡‡

Insider Outsider
Handled internally without involving legal action or law enforcement 72% 75%
Handled internally with legal action 13% 6%
Handled externally by notifying law enforcement 14% 18%
Handled externally by filing a civil action 2% 1%

At the 2013 RSA Conference in San Francisco, Patrick Reidy of the Federal Bureau of Investigations (FBI) shared five lessons-learned for security practitioners based on the FBI’s experience investigating malicious insider threats.
  • Insider threats are not hackers.
    • The Insider Threat Study in 2008 by CERT and the National Threat Assessment Center (NTAC) describes several key findings:††
      • A specific event or series of events triggered most insiders’ actions.
      • Revenge was reported as the main motive in just over half the cases.
      • Frequently reported goals of insider attacks included financial gain, theft of information and sabotage to the organization.
    • The first step to mitigation is gaining an understanding of the motivation of the malicious insider.
  • Insider threat is not a technical or "cybersecurity" issue alone.
    • Mitigating insider threats calls for controls that move beyond IT and include solutions that are people-centric.
    • Successful mitigation strategies look at the interplay between business processes and information technology.
    • “Adopt a multidisciplinary whole threat approach”
  • A good insider threat program should focus on deterrence, not detection
    • Create an environment that makes it “really difficult or uncomfortable to be an insider.”
    • Crowdsource security, i.e. solicit input from the user community on how to improve controls to protect data
  • Avoid the data overload problem
    • Deploy data filters
    • Periodic audits
    • Implement segmentation of duties
  • Use behavioral based techniques for detection of insider threats
    • “Base detection on user’s personal cyber baselines”
    • “The idea is to detect insider bad behavior closer to that tipping point of when a good employee goes rogue.”
The following table describes some differences between insider and outsider threats and point to why insider threats demand special categorization.

Trusted Untrusted Insiders have intimate knowledge and are able to sidestep security measures more easily without raising alarm.
Legitimate Access Unauthorized Illicit activity by insiders can more easily be masked as authorized because they have legitimate access to the resource.
Operational tools Specialized tools Relatively low-tech tools can be deployed by insiders as they are already behind the firewall, already know the administrator password, etc.
Revenge Financial The motivation of the insider is usually less sophisticated, however in many cases, it is also less predictable and more expensive to prevent or detect.
Insider vs. Outsider Threats

As in most cases, effective security measures calls for a multi-layered approach to security. To mitigate malicious insider threats, in addition to technology-based deterrents such as firewalls, intrusion detection systems and monitoring, behavioral and policy-based deterrents should also be deployed.

Behavioral and policy-based deterrents include tools such as acceptable use policies (AUP), background checks, account management policies and segregation of duties. In a 2006 E-Crime Watch Survey conducted by the United States Secret Service (USSS), the SEI CERT Program, and CSO Magazine, the top five security policies and procedures used by organizations in the survey were:‡‡
  1. Account/password management policies
  2. Acceptable use policy/ Formal “inappropriate use” policy
  3. Employee/contractor background check
  4. Employee education & awareness programs
  5. Conduct regular security audits
Here are some best practice considerations suggested by various security principles:
  • Monitor how users interact with information
    • Establish a baseline of normal user behavior with respect to data and resource usage, conduct trending analysis and alert on deviations from baseline with respect to data movement, channels and usage.
    • Log, monitor, and audit employee online actions
  • Anticipate and manage workplace issues across the employee lifecycle
    • Deploy policies and procedures designed to monitor, manage and respond to disruptive and suspicious behavior.
    • Deactivate computer access following termination
  • Implement comprehensive and consistent information controls to minimize data exfiltration
    • Require accountability regardless of endpoint (e.g. desktop, tablet, smartphone)
    • Employ controls across all information states (at rest, in motion, and in use) and across all endpoints (network, tablet, desktop, smartphone, etc.)
    • Understand, monitor and lock down all exit points for data, e.g. wireless, removable media, fax/printers, social media, FTP, etc.
    • Implement secure backup and recovery processes
  • Institute stringent access controls and monitoring policies on privileged users
    • Institutionalize system change controls
    • Centralize security control management for rapid incident identification, analysis, and response
    • Enforce separation of duties and least privilege
    • Define explicit security agreements for any cloud services, especially access restrictions and monitoring capabilities
    • Use a log correlation engine or security information and event management (SIEM) system to log, monitor, and audit employee actions
    • Collect and save data for use in investigations
  • Institute periodic security awareness training for all employees
Related Terms: stochastic forensics