Content Server Security – Challenges and Best Practices

1
Content Server Security Challenges and Best
Practices
Brian Bex Huff, Software DeveloperStellent,
Inc.
January 30, 2006
2
Purpose

• Outline what you need to protect your content
• How Content Server fits into your security policy
• Use risk-management to minimize cost
• Discuss risks and known vulnerabilities
• General network briefly, Stellent in detail
• Present countermeasures to mitigate risks
• General network briefly, Stellent in detail

3
Brief History of Internet Security

• Early days
• Little security except governments, banks, and
  telcos
• Most software was far too trusting
• First virus (1983), worm (1988), and trojan (1200
  BC)
• Networks must defend against malware
• Sparked battle between cryptographers and US
  government
• Tech boom
• http//www.BURN-PILES-OF-MONEY.com
• Spent on security, but didnt understand it
• Tech bust
• All projects must justify expense, security was
  neglected

4
Brief History of Internet Security, cont.

• Today
• Little security except governments, banks, and
  telcos
• The Future
• Annoying/disruptive malware is for amateurs
• Intellectual property theft is the future
• Cheap and effective industrial espionage
• Database, file server, web-based CMS are next
  targets
• Popularity of web services will lead to new
  attack forms

5
Cyber Crime Statistics

• Affected 55 million Americans in 2005 (USA Today)
• Yearly costs estimates vary wildly
• 105 billion (2005, Treasury Department)
• 1 billion (2003, Gartner)
• 42 of Americans used internet LESS in 2005
• Identity theft scares them away (Gartner)
• Customers go elsewhere after security breaches
  (Ponemon)
• 70 would leave after two thefts of customer data
• Each customer record lost costs 75

6
What Should We Do?

• Dont panic!
• 100 security neither possible nor cost-effective
  
• Ultimately, people make your assets secure
• Security products (hardware, software) merely
  assist
• Make your network defensible
• Consider security like risk management
• Security breaches always possible
• Can lower the odds, for progressively more money
• Minimize risk for the minimum price
• Security is a process, not a product Bruce
  Schneier

7
Making A Security Plan

• Determine risks and threats
• Who is attacking you, and why?
• Describe policy required to defend
• Who should be allowed to do what?
• Sarbanes Oxley compliance may also require this
• Analyze vulnerabilities, design countermeasures
• Cover all aspects Protection, Detection, Reaction

8
1) Determine Threats and Risks

• Definition of Risk
• Probability and effects of a harmful event
• Risk Threat x Vulnerability x Impact
• Threat person with skills and motive to leverage
  vulnerability
• Standard Consumers LOW Risk
• Customers, partners, site visitors, Google
• Using leaked information against you
• Contributors MEDIUM Risk
• Typical employees, Site Studio contributors
• Information leakage, bad passwords, malicious
  content

9
1) Determine Threats and Risks, cont.

• Administrators HIGH Risk
• Site maintainer
• Setting security improperly, stealing content
• Developers HIGH Risk
• Component, fragment, or portal designers
• Creating insecure code on your system
• Unauthorized Users HIGHEST Risk
• Hackers, malware, ex-employees, differs based on
  organization
• Oft cited stat 70 of attacks are insiders

10
2) Determine Security Policy

• Specifics depend on organizational needs
• Enterprise network policy
• General process for users, administrators,
  applications
• Most likely you have one already
• Content Server specific policies
• Who is allowed to view/change each type of
  content?
• When is content fit for consumption?
• Do contributors need access to scripting
  languages?
• JSP, ASP, JavaScript
• Which add-ons and components are secure?

11
3) Vulnerabilities and Countermeasures

• Protection, Detection, Reaction
• Vulnerabilities common to all enterprise systems
• Security holes in OS, web server, database
• Bad passwords, eavesdropping, malware
• Evil developers and administrators
• Probably addressed in your current security
  policy
• Vulnerabilities common to web apps
• Cross Site Scripting (XSS)
• Information leakage

12
Vulnerabilities in Stellent

• Java-based, immune to buffer overflows
• Primary vulnerabilities in interfaces
• Connection to authentication engine
• Web server, portal server, LDAP
• Database connections (SQL injection)
• Administrative tools can impersonate users
• Contributors uploading insecure content
• Incorrect security group
• Malicious ASP / JSP / JavaScript / HTML Forms
• Insecure components

13
Protection - High Risk Vulnerabilities

• Important regardless of your organization
• General network security
• Cross site scripting
• Malicious content
• Content server port access

14
General Network Security

• Keep software/firmware patches up-to-date
• 99 of attacks are known exploits (CERT)
• Vulnerability analysis tools (Nessus, Metasploit)
• Highly flawed, but catches known exploits
• Secure network topology
• Firewall both external and internal attacks (DMZ)
• Minimize required trust and single points of
  failure
• Restrict physical / shell access
• Virus/Trojan scanners at internet gateway
• Block malicious emails web downloads
• Cannot trust users to make secure decisions!

15
Cross-Site Scripting (XSS)

• HTML HTTP flexibility very useful
• Form on my site to submit a Google search
• Click submit, search results displayed in your
  browser
• But could cause security problems
• Click submit, content deleted from your server
  invisible to you
• Attacks can originate from ANYWHERE
• Form submission, URLs, or simple page loading
• Attacks can be JavaScript, or pure HTML
• Executed with your browser security credentials
• Hacker tricks you into attacking the server for
  him
• Advanced attacks with AJAX can hijack your entire
  browser!

16
Cross-Site Scripting, cont.

• Block forms submitted from untrusted sites
• Block insecure HTTP referrers (HtmlPostAuthenticat
  or)
• Can be spoofed, in this case its usable
• Block malicious URLs EnableSecuredGetstrue
• Scrub XSS attacks from request data
  (FilterDataInput)
• Blocks JavaScript in metadata, content, URL
  parameters
• Especially important for anonymous contributors
• Comments forms, resume submissions
• Significantly restricts your power users

17
Malicious Content

• Virus scanner on stellent/vault/temp directory
• Checks for malicious / careless contributors
• Lock down JSP/ASP contribution to just developers
• Lock down JSP with JspEnabledGroups
• Enable ASP only for specific security groups
• http//myhost/stellent/groups/scripts/
• Remove secure data from JSPs/ASPs
• Consumers with access to native file can view the
  source
• Malicious HCSP same as malicious HTML
• IdocScript limited to page display for security
  reasons

18
Direct SCS Port Access

• Authentication performed outside of SCS
• Web server authenticates, passes username to port
  4444
• Out of the box, only localhost is trusted
• With dedicated server trusted admins, fairly
  safe
• Rogue administrator can impersonate users
• Content Integration Suite (CIS), IdcCommandUX
• SOAP is safer password authenticated by web
  server
• First block access with firewalls
• Block all but web server and portal server
• Restrict to specific users if possible
• More safe than just SocketHostAddressSecurityFilte
  r

19
Direct SCS Port Access, cont.

• Second password secure access (ProxyConnections)
• Set ProxyPassword to a large random string
• Web server sends secure authentication token
• User, hashed user password, IP, time, and
  ProxyPassword
• Blocks connections without token
• Some admin tools blocked
• Manually create token for portal servers (CIS,
  IdcCommandUX)
• Or Third encrypt access with SSL
  (SecurityProviders)
• CIS only, default web server not yet supported
• Authenticate with SSL certificates
• For systems with extraordinary needs

20
Protection - Lower Risk Vulnerabilities

• Less important, depending on organization and
  network
• Data leakage
• Eavesdropping
• Passwords
• Hacked database, file server, web server

21
Data Leakage

• How much does Google know about you?
• Simplify the security model
• Less accidental information leakage
• Use security groups to secure, not to organize!
• Use Profiles / WebDAV to simplify contribution
• Workflows for public facing content
• PDF Watermark, Dynamic Watermark
• Embed the word CONFIDENTIAL in converted PDFs
• Add date and viewers name with Dynamic Watermark
• NeedToKnow component
• User can view some metadata, but not content

22
Eavesdropping

• Network vulnerable to packet sniffers
• Spy on downloaded content or passwords
• Use SSL (HTTPS)
• Protects passwords and content
• Important for Basic authentication and cookie
  login
• NTLM authentication is already encrypted
• Drawback performance suffers
• Customizations use SSL only when needed
• Login with cookies from HTTPS page
• Set up both HTTP and HTTPS (BrowserUrlPath)
• Use SSL only for contributors / administrators

23
Password Hacking

• Cannot trust users with their passwords
• 70 give away passwords for chocolate (BBC)
• Computers getting faster, passwords still 8
  letters
• Reused passwords, easily guessed passwords
• Use Single Sign On (SSO)
• NTLM, Active Directory, LDAP, Netegrity
  SiteMinder
• Eases maintenance of passwords, users, new
  applications
• Drawback no login prompt can make XSS worse
• Dont allow users to know their access key!
• USB / smart cards with SSL certificates for
  authentication
• Protect certificate with password
• Add biometrics for more security
• In practice, managing such keys is very difficult

24
Hacked Web Server

• Web server primary target for unauthorized users
• Typically exposed to outside world
• Firewalls help, but dont stop everything
• Password secure SCS / web server connection
• Require access tokens (ProxyCredentials)
• Hacker cannot impersonate users
• Web proxy for extra security layer
• Run web server on same machine as SCS
• Connect to web server with proxy (Squid) outside
  firewall
• If proxy is hacked, SCS is still safe (for now)

25
Hacked File System

• Compromise of SCS machine or file server
• If user gains root access, anything is possible
• Use NTLM/Kerberos authentication for Database
• No need to store JdbcPassword
• SQL Server Use JTDS 1.2 driver, manual install
• Oracle Use version-specific thin driver
• Encrypted file system
• Secure the vault, weblayout, search, data
  directories
• Performance loss, might not work with web server
• Expanded support with FileStoreProviders (8.x)

26
Database Connections

• SQL Injection attacks
• Similar to XSS malicious SQL through hacked web
  form
• Can take over database through some web
  applications
• SCS protected by abstraction layer
• SQL in predefined queries, strongly typed
  parameters
• SCS validates user-submitted data
• Parses dates, numbers, escapes quotes in strings
• Extra parenthesis added if found in query terms
• Reduce table-modification rights of Stellent JDBC
  user
• Adding metadata, schema, components requires DBA
  approval
• User-level activity unaffected

27
Protection - Risks in Customizations

• Difficult to measure
• Untrusted developer making customizations
• How to make secure components
• Possible security customizations

28
Malicious Components

• Difficult to defend against
• Requires complete auditing of code for back-doors
• Install development servers
• Protects content against rogue developers
• Components audited and installed by trusted admin
• Block Admin Server component installs
• Restrict to Component Wizard from the console
• AllowUpdateComponentConfig, AllowComponentUpload

29
Secure Component Tips

• Validate HTML form data in Java
• JavaScript is handy, but not trustable
• Encode IdocScript variables on pages
• IdocScript functions js(), xml(), url()
• Prevents introduction of new XSS attacks
• Use predefined SQL queries, avoid raw SQL
• Predefined queries thwart SQL injection
• Execute command-line applications with caution
• Validate the command first

30
Secure Component Tips, cont.

• Use the checkSecurity action in custom services
• Service security flags require dSecurityGroup to
  be present
• Cannot trust values sent by the user
• First determine dSecurityGroup with SQL query
• Then call checkSecurity action in service
• Expect people to call custom IdocScript
  maliciously
• Restrict functionality to read-only actions
• Workflow IdocScript allows write actions in
  special context
• Condition variable allowWorkflowIdocScript

31
Security Customization Examples

• Modify security with Java components
• Web security plugins require C code
• Allow anonymous user to check in content
• SecurityFilter component in 7.5 HowToComponents
• Deny general access, allow it for specific
  requests
• Establish download quotas
• User can only download 50MB per day
• Block certain service calls for consumption
  servers
• Block SOAP or WebDAV explicitly
• With firewall, or customization
• Block all services except bare essentials
  (SS_GET_PAGE)

32
Security Customization Examples, cont.

• Custom validation of metadata and content
• Content Profile rules, or Java filters
  (validateStandard)
• Java User Providers for authentication
• For legacy or atypical authentication protocols
• Custom web authentication
• Custom authentication filters (SiteMinder, SSL
  Certificates)
• Custom tokens for flexible SOAP security
• Block login after 3 bad passwords
• Custom cookie login
• Existing sample version doesnt have a timeout
• Be sure to hash the username, a timestamp, and a
  secret

33
Detection Network Violations

• Check logs frequently
• Firewall, intrusion detection, web server
• Sometimes only human eyes catch suspicious
  behavior
• Syndicate access logs to remote servers
• Must compromise several systems to cover your
  tracks
• Intrusion detection systems (Snort, some
  firewalls)
• Detects known attacks, generally suspicious
  packets

34
Detection SCS Specific

• Check SCS web logs
• Access violation logged
• Login failures not automatically logged
• Use SSO or custom component
• Content Tracker
• Tracks popularity who viewed what?
• Check for allowed but unusual activity
• Downloading data before quitting
• Downloading random highly secure data
• Excellent dual-purpose technology

35
Reaction Respond to Intrusion

• Someone someday will bypass all your security
• Reaction depends on business needs
• Block access with firewall? Unplug from network?
• Minimize damage and disruption while you patch
• Establish backup and recovery plans
• Backup all applications and data
• Most high-availability sites have sufficient
  plans
• Redundancy is primary
• System must survive a crash / compromise of one
  server
• One compromise shouldnt lead to several

36
Reaction SCS specific

• Block hacked user accounts
• Supported by some SSO vendors
• Block the administrator (SysadminBlocker)
• Make database read-only
• Block commit rights to Stellents JDBC user at
  the database
• Blocks ALL write activity, possible side effects
• Make Counters table read-only
• Blocks all transactions

37
Conclusions

• Stellent less vulnerable than most systems
• Smaller target than operating system, database
• Recommendation block XSS and direct port access
• Others countermeasures as needed
• Which countermeasures to use?
• First, use dual-purpose technology
• SSO, web proxies, Content Tracker
• Second, select those with little cost/drawbacks
• ProxyCredentials, SSL, simplified security model
• Lastly, select those with significant
  cost/drawbacks
• Scrub JavaScript content, SSL Providers, custom
  components

38
Useful Links

• Security Books
• Secrets Lies http//www.amazon.com/gp/product/0
  471453803
• Source for some material presented here
• Counter Hack http//www.amazon.com/gp/product/013
  1481045
• Hacking Exposed http//www.amazon.com/gp/product/
  0072260815
• Network Security http//www.amazon.com/gp/product
  /0072226978
• Tao of NSM http//www.amazon.com/gp/product/03212
  46772
• Open Source Tools
• Vulnerability Analysis http//www.nessus.org/
• Intrusion Detection http//www.snort.org/
• Packet Sniffer http//www.ethereal.com/

39
Questions?

• Contact Information
• Brian Bex Huff ltbex_at_stellent.comgt
• http//www.stellent.com
• http//groups.yahoo.com/group/intradoc_users/
• See Session 1502 on SSO Integrations
• See Session 908 on Disaster Recovery
• Please complete the session survey before you
  leave today
• Access this presentation and materials at
• http//www.stellentcrescendo.com/Crescendo/Session
  s/index.htm
• Log-in and password required to access
  presentations (watch for an email containing your
  codes)