Jairam RameshSecurity Research Consultant | Microsoft [email protected]
Agenda
Internet Attacks
IIS 7 and comparison with its predecessors
Counteracting the various attacks!
Common Types of AttacksBuffer Overflow
Cross-site scripting
SQL Injection
Canonicalization
Authentication
Brute force attacks
Dictionary attacks
Cookie replay attacks
Credentials theft
Authorization
Disclosure of confidential data
Configuration management
Unauthorized access to administration interfaces
Unauthorized access to configuration stores
Retrieval of plain text configuration secrets
Lack of individual Accountability
Over-privileged process and service accounts
Sensitive Data
Network Eavesdropping
Common Types of AttacksData tampering
Luring Attacks
Session Replay
Man in the middle attacks
Cryptography
Weak Encryption
Denial of Service
Session Hijacking
Parameter Manipulation
Query String manipulation
Form field manipulation
HTTP Header manipulation
The basic foundation
Scalability
Security
Trust
A solid foundation to build IIS 7 was already set by IIS 6
Notes
•MS02-011 & 012 not included: updates SMTP service
only
•ASP.NET adds: 1 – v 2.0 2 - v 1.1 3 - v 1.0
= Critical
= Rollup with
X updatesX
IIS
6
IIS
5
2002 2003 2004 2005
IIS
4
4/15
Server2003
RTM
4/10
02-018
6/11
02-02810/30
02-0625/28
03-018
10/12
04-021
(WebDA / DoS)
7/13
04-021
8
8
4
4
4
4
< Critical
2006
06/11
06-034
(ASP)
http://secunia.com/advisories/product/1438/?task=statistics
IIS 7 Security Features
Modular Design:Reduced exposure at installation and runtime
.NET Integration:Forms Authorization for any content
Use of .NET Role and Membership Providers
Built in anonymous accountEasier to administer, restore, and configure
Application Pool IsolationImproved Sandboxing between applications
URLAuthorization and Request FilteringNew choices for improving security
Kernel mode SSL and authenticationFaster negotiation of security exchanges, fewer problems
Reduced Footprints
Features implemented as discrete modules
Modularity improves security
Reduced module set by default at install
Remove modules that you do not need
Extensibility allows security customization
Add authentication, logging, or blocking mechanisms
.net provided Security Features
Integrated pipeline enables Forms authentication with any content
Leverage existing user database with .NET Role/Membership providers
Examples: Store user names in:Active directory or local SAM
SQL 2005 Express for static site users
ADAM for users and groups in a PHP application
DB2 mainframe users and groups in ASP.net
Introducing IIS 7 Features
URL AuthorizationControl access to sites, folders, or files without using NTFS
Inspired by ASP.net URL authorization, but designed for administrators
Rules are stored in .config files
Delegate control to store in web.config
Authorization rules are then portable
Xcopy and maintain security
Use Windows principles or .NET provider
URL Authorization
Request Filtering Error Codes
Request Filtering
Changes in Anonymous Users
IUSR instead of IUSR_<servername>
IUSR is ―built in‖, not a local accountCannot logon to system with this account
No password to worry about
Same SID on all Vista/LH servers
File ACLS are valid between servers
Allow anonymous access & turn off IUSR:Use process identity for anon access when enabled
Disabled by default
Security Features moved to Kernel
Kernel Mode SSLImproves performance
Reduces context switch to user mode
Kernel Mode AuthenticationImproves performance
Kerberos functions when using custom application pool identity!
No need to use SETSPN as access to DC occurs as machine account
Encypting keys in web.config
Passwords may be present in .configNo secrets by default
Passwords are needed for:UNC paths
Shared Configuration
Custom Anon or App Pool identity
Passwords are encrypted when addedAES provider is the default
Encryption provider can be customized
Encrypting the web.config
Security Checklist
• No IIS on a domain controller
• Install only services needed (ftp, www, smtp, nntp).
• Virtual directories are NEVER used across servers.
• The underlying Windows OS has been secured.
• Only system administrators are local administrators.
General Assumptions
Security Checklist
• Websites should NEVER be on the system drive.
• Setup SSL if transmitted information is sensitive.
• All FTP sites, and as needed WWW sites should enable IP filtering for Stanford-only sites. IPSec filters can be used to accomplish this.
• Virtual directories should be used as little as possible. \
• Remove NTFS write perms everywhere possible.
• Don’t make it easy to find your scripts and code.
Consider renaming the extension on all of your scripts to something uncommon.
Consider compiling scripts into dll files.
Web applications (i.e. scripts and executables) only need a limited amount of permissions to run properly
Be careful when using the Add/Remove control panel on an IIS Server.
Design Guidelines
Security Checklist
• Delete all default virtual directories (icon w/ world on top of folder) and application roots (icon w/ green ball in box)
• Delete iisadmin
• Delete iissamples
• Delete msadc.
• Delete iishelp
• Delete scripts
• Delete printers
• Delete ALL default content.
• Delete %systemdirectory%\inetsrv\iisadmin
• Delete %systemdirectory%\inetsrv\iisadmpwd
• Delete inetpub\wwwroot (or \ftproot or \smtproot)
Installation Configuration
Security Checklist
Delete %systemdrive%\program files\common files\system\msadc.
Configure Default Website with extremely secure
Configure all website(s) with host header matching the DNS name of the site.
Home directory IIS perms: Enable Read and Log. TURN OFF Write, Index, Browsing, Script Source Access (only WebDAV uses this), and Frontpage Web permissions. Set execute permissions to None. Enable execute permissions for the directory that holds your scripts.
Disable all unnecessary ISAPI filters. Do this under ISM, ISAPI filters tab.
Installation Configuration
Security Checklist
• Delete the Frontpage ISAPI filter (or extensions on older IIS servers), if you have a choice. If Frontpage ISAPI (extensions) is required, make them read only.
• Digest Authentication. This authentication method requires support for reversibly encrypted passwords—which is a bad idea
• HTTP Compression. This filter allows compression of the http stream.
• SSL. It’s unlikely you wouldn’t want SSL support, but if you don’t need it, then delete it.
Installation Configuration
Security Checklist
Delete the dll files associated with ISAPI filters that you disabled. FrontPage: fpexdll.dll, Digest: md5filt.dll, Compression: compfilt.dll, SSL: sspifilt.dll.
Unmap the following extensions (if possible):.asa, .asp, .bat, .cdx, .cer, .htr, .htw, .ida, .idc, .idq, .printer, .shtm, .shtml, .stm.
Within ISM, go to the Home Directory tab, and choose Configuration button.
Disable ―Enable Parent Paths‖ setting. Go to ISM, Home Directory tab, Configuration button, App Options tab, uncheck checkbox.
Installation Configuration
Security Checklist
Basic authentication disabled at site level, virtual directory level, directory level –Everywhere!
Digest authentication disabled everywhere.
IUSR & IWAM accounts should not be domain users nor should they be guests. If no anonymous access is required, delete these accounts.
If web data is ultra-sensitive consider placing server outside a domain.
Authentication Mode
Security Checklist
Enable IIS auditing, change to W3 extended logging, and check that the info that is being logged is appropriate.
Set permission to IIS logs to system and local administrators only.
Remove write perms to hklm\software for non-admin accounts. Administrators & System: FULL, Everyone: Read/Execute
Restrict NTFS perms to ALL executables on system. NTFS perms: Administrators & System: FULL, Users: Read/Execute. Give IUSR account execute permissions sparingly.
Restrict perms to any script interpreters such as perl. NTFS perms: Administrators & System: FULL, Everyone: Read/Execute. Give IUSR account execute permissions sparingly.
Ensure Everyone has only read on:―Web root‖―%systemroot%‖ ―%systemroot%\system32‖ ―%systemroot%\system32\inetsrv‖ ―%systemroot%\system32\inetsrv\asp‖ ―%systemroot%\program files\common files\‖
Authorization Changes
Counteracting
Buffer Overflow
Perform thorough input validation
Wherever possible, limit application's use of unmanaged code
If unmanaged API is called in your application, check the values passed for the parameters of unmanaged API to avoid this attack
Compile your code with /GS flag if it is developed in Microsoft Visual C++ system. The /GS option detects some buffer overruns, which overwrite the return address - a common technique for exploiting code that does not enforce buffer size restrictions. This is achieved by injecting security checks into the compiled code.
Counteracting
Cross-site scripting
Perform thorough input validation on form fields, query strings, cookies. Always check for scripting tags and filter the same. Regular expression is the best way of validating input
User inputs should be encoded using HTMLEncode and URLEncode functions
Counteracting
SQL Injection
Validate the input received by the application using regular expression
Set appropriate privileges to execute the SQL commands
Stored procedures executed using arguments should be parameterized stored procedures
Counteracting
Network eavesdropping
Use Kerberos authentication or Windows authentication which doesn't transmit the password over the network
When there is a necessity for transmitting password through network, use an encryption communication channel like SSL which will encrypt the contents passed through network channel
Counteracting
Brute force attacks
Use strong passwords with that are complex. Use mixture of uppercase, lowercase, numerals, special characters in the password that makes difficult to crack.
Store non-reversible password hashes in the user store. Also combine a salt value with the password hash.
Counteracting
Cookie replay attacks
Use SSL that encrypts all the information including cookie information passed through the channel
Always use timeout property for the cookie information. This will reduce the probability of attack.
Counteracting
Data tampering
Use tamper resistant protocols such as hashed message authentication codes.
Counteracting
Session Hijacking
Avoid storing anything in the session objects.
Implement SSL as it will encrypt all the information that is transmitted via the network
Allow only one session per user at a time.
Incase if SSL is not implemented and still there is a need to store information in the session object, ensure you set a time period for expiry.
Counteracting
Session Replay
Do not store authentication information on the client
Whenever a critical function is being called or an operation is performed, re-authenticate the user
Set expiry date for all cookies
Counteracting
Man in the middle attacks
Use strong encryption.
Use Hashing.
Counteracting
Denial of Service
Each individual input received from the user should be thoroughly validated
Handle all types of exception in your application through out the code base
Auditing & LoggingEnable auditing and logging in web server, database server and application server.
Identify the key events and log them. For eg. Login, logout events
Avoid shared accounts. It will lead to difficulty as we cannot trace out the original source
All critical application level operations should be logged
Read the log files every day to detect suspicious activity. Always maintain the back up of log files
If the platform provides any support to log important transactions, make use of that.
Do not keep the log files in the default location folder. Move it to a different location.
Secure log files using Access Control Lists
References
ASP.NET 2.0 Internet Security Reference Implementationhttp://blogs.microsoft.co.il/files/folders/36103/download.aspx
Official Microsoft IIS Sitehttp://www.iis.net/
Feedback / QnA
Your Feedback is Important!
Please take a few moments to fill out our online feedback form at: << Feedback URL – Ask your organizer for this in advance>>
For detailed feedback, use the form at http://www.connectwithlife.co.in/vtd/helpdesk.aspx
Or email us at [email protected]
Use the Question Manager on LiveMeeting to ask your questions now!
© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.