Your SlideShare is downloading. ×
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Bh Win 03 Rileybollefer
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Bh Win 03 Rileybollefer

726

Published on

Surviving OpenHack 4, Steve Riley, Timothy Bollefer, Microsoft Corporation

Surviving OpenHack 4, Steve Riley, Timothy Bollefer, Microsoft Corporation

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
726
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Surviving OpenHack 4 Steve Riley and Timothy Bollefer Microsoft Corporation
  • 2. Yes we can
    • Believe it!
    • Any reasonably skilled administrator can build a Windows environment that is secure and resilient against attack
    • You’ll learn today how we won the latest OpenHack competition by eWeek
    • You can use these principles today on your own deployments
  • 3. System components
    • Web application
    • IIS 5.0
    • Windows 2000 AS
    • IPSec policies
    • Remote management and monitoring
    • SQL Server 2000
    • Passwords
    • Keep this in mind: we used no firewalls!
  • 4. Web application
  • 5. Web application
    • Built on eWeek’s eXcellence Awards web site
      • User sets up account
      • Enters a product or service for judging
      • Submits a credit card number to pay entry fee
      • Read information about award
    • Built with .NET Framework
      • ASP.NET
      • ADO.NET
      • Cryptography class libraries
  • 6. Web application User authentication
    • ASP.NET provides many options
      • Integrated Windows authentication
      • Basic
      • Digest
      • .NET Passport
      • Client certificate
      • Forms (custom)
    • eWeek requested forms
  • 7. Web application Forms authentication
    • POST user name and password over SSL
    • Use encrypted cookie to keep logon session
    • Unauthenticated users can access home page (and a couple others)
      • Requests to secure pages get redirected to logon page
  • 8. Web application Page protection
    • Request forms authN with three lines of code
      • <system.web> section of Web.config file in application’s root folder
      • Applies to all pages in application
    • Protect certain pages in subfolder with a little more code
      • Add another Web.config here
      • Inherits authN info from top-level file
      • Denies access to unauthenticated users
  • 9. Web application Page protection—request authN
    • <authentication mode= &quot; Forms &quot; >
    • <forms loginUrl= &quot; Login.aspx &quot; name= &quot; OPSAMPLEAPP &quot; />
    • </authentication>
  • 10. Web application Page protection—required authN
    • <?xml version= &quot; 1.0 &quot; encoding= &quot; utf-8 &quot; ?>
    • <configuration>
    • <system.web>
    • <authorization>
    • <deny users= &quot; ? &quot; />
    • </authorization>
    • </system.web>
    • </configuration>
  • 11. Web.config files demo
  • 12. Web application Account creation and login
    • New account
      • Encrypt password with 3DES
      • Store in database with user name
    • Login to existing account
      • Encrypt password with 3DES
      • Compare with encrypted password in database
      • Create cookie and send to user
        • System.Web.Security.FormsAuthentication class
    • All over SSL
      • Prevents replay attacks
  • 13. Web application Input validation
    • Critically important security function
    • Ensure user input doesn’t change application’s behavior
    • Helps guard against—
      • Buffer overruns
      • Cross-site scripting
      • Malicious code execution
  • 14. Web application Input validation
    • Requires multiple layers
      • Plan for the worst
      • Assume one or more tiers could be compromised
    • Four checks
      • Validate all field input
      • Validate query string portion of URL
      • Use stored procedures with type-checked parameters
      • HTML-encode all data sent to users
  • 15. Web application Input validation—1 st check
    • Two ASP.NET classes
      • RegularExpressionValidator
      • RequiredFieldValidator
    • Limited input characters to space, apostrophe, comma, period, letters, numbers
    • Other characters blocked
      • Commonly used to upload malicious code
  • 16. Web application Input validation—2 nd check
    • Parse URL query string
      • System.Text.RegularExpressions.Regex
    • Validate input with regular expression
      • Allow numbers only
    • Regex isNumber = new Regex( &quot; ^[0-9]+$ &quot; );
    • if(isNumber.Match(inputData) ) {
    • // use it
    • }
    • else {
    • //discard it
    • }
  • 17. Web application Input validation—3 rd check
    • Use stored procedures for data access
      • Limits app’s interaction with database
      • Strongly-typed parameters
    • Allowing web app to dynamically build queries is baaaaad!
      • Whacked web server  arbitrary code injection
    • Input parameters are type-checked first
  • 18. Web application Input validation—4 th check
    • HTML encode all data sent back to user
      • HtmlEncode method in System.Web.HttpServerUtility class
    • Prevents cross-site scripting attacks
      • Compromise database  enter script in records  return to user  execute in browser
      • Script commands translated to harmless text
    • SomeLabel.Text = Server.HtmlEncode(username);
  • 19. Input validation code demo
  • 20. Web application Storing secrets
    • Need to protect two kinds here
      • Database connection/login string
      • User password and credit card information
    • Use different approaches for each
  • 21. Web application Storing secrets—connection string
    • Web app needs to authenticate to database
    • Usual method is to store ID/password in code
      • Holy grail for an attacker
    • Use integrated Windows authN
      • String contains only server location and DB name
      • Stored in “code-behind” file—core app logic
        • Not user interface definition files
    • Still not enough
      • Attacker on physical machine could read file
      • So…
  • 22. Web application Storing secrets—connection string
    • Encrypt string using data protection API (DPAPI) functions
      • CryptProtectData and CryptUnprotectData
      • Encrypts secrets without having to manage or store keys
    • Store string in registry
    • ACL the registry key—
      • Administrators
      • ASPNET worker process
  • 23. Web application Storing secrets—user info
    • DPAPI is less useful here
      • Keys based on local machine information
      • Each web server in the farm would have its own key; can’t access shared info this way
  • 24. Web application Storing secrets—user info
    • Generate 3DES encryption key and initialization vector
      • TripleDES class in System.Security.Cryptography
    • Symmetrically encrypt password and credit card number stored in DB
      • Salt: cryptographically strong random first block
    • Encrypt key and IV with DPAPI and store in ACLed registry on each web server
  • 25. Code for storing secrets demo
  • 26. Internet Information Services 5.0
  • 27. IIS 5.0
    • Updated service packs and security patches
    • Moved default web site
    • Ran IISLockDown tool
    • Installed and updated .NET Framework
    • Remapped extensions
    • Configured account privileges and permissions
    • Installed URLScan
    • Added ACLs to application folder and logs
  • 28. IIS 5.0 Default web site location
    • Move out of %systemdrive%inetpub
    • Put in different folder on different volume
    • Attacker needs to see directory tree now
      • Can’t access the system drive with ..
  • 29. IIS 5.0 IISLockDown
    • Use static web server template
      • No need for dynamic content types in this app
      • Will modify in a bit
    • Get it now: http://microsoft.com/technet/security/tools/tools/locktool.asp
  • 30. IIS 5.0 .NET Framework
    • Redistributable: http://msdn.microsoft.com/downloads/sample.asp?url=/msdn-files/027/001/829/msdncompositedoc.xml
    • Service pack 2: http://msdn.microsoft.com/netframework/downloads/updates/sp/default.asp
    • Latest hotfix (cred strengthening): http://support.microsoft.com/default.aspx?scid=kb;en-us;Q329250
    • MDAC 2.7: http://www.microsoft.com/data/download.htm
  • 31. IIS 5.0 Remove extension mappings
    • Need only .aspx and a few static content types
    • Remap other application extensions to 404.dll extension
      • Included with IISLockDown
  • 32. IIS 5.0 Account privileges and perms
    • Use default local ASPNET service account
      • Created during Framework installation
      • Placed in Users local group
      • Also receives—
        • temporary ASP.NET folder: full
        • %windir% emp : full
        • Framework installation folder: read
    • Add this account to local Web application group created by IISLockDown
      • This group can’t run executables
      • Update group’s perms to run the C# compiler and resource converter
  • 33. IIS 5.0 URLScan
    • Part of IISLockDown
    • Parser examines URL before passing it to IIS
    • Configuration—
      • Allow only the app’s extensions
      • Block long requests
    • More details: http://www.microsoft.com/technet/security/tools/tools/urlscan.asp
  • 34. IIS 5.0 Folder and log ACLs
    • Web content folders—
      • ASP.NET worker process: read
      • Anonymous: read-only on served content
    • Log folders—
      • System account and Administrators group only
      • All others: deny
      • IIS and URLScan logs
  • 35. IISLockDown Extension remapping Accounts URLScan Folder/log ACLs demo
  • 36. Windows 2000 Advanced Server
  • 37. Windows 2000 AS
    • Updated service packs and security patches
    • Disable unused OS services
    • Various registry-based tightenings
  • 38. Windows 2000 AS Unused services
    • Alerter
    • Appmgmt
    • Bits
    • Browser
    • Clipsrv
    • Dfs
    • Dhcp
    • Fax
    • Ismserv
    • Kdc
    Baseline template disables these:
    • Messenger
    • Mnmsrvc
    • Msdtc
    • Netdde
    • Netddedsdm
    • Ntfrs
    • Rasauto
    • Rasman
    • Remoteregistry
    • Sharedaccess
    • Spooler
    • Tapisrv
    • Tlntsvr
    • Trksvr
    • Trkwks
    • Utilman
    • Winmgmt
    • Wmi
    • Wuauserv
  • 39. Windows 2000 AS Unused services
    • SQL Server
      • Lanmanserver—manual
      • Sqlserveragent—disabled
    • Terminal server
      • Lmhosts—disabled
    • Web server
      • Lanmanserver—disabled
    • VPN server
      • Rasauto, Rasauto, Lmhosts, Tapisrv, Remoteregistry—automatic
  • 40. Windows 2000 AS Reg tweaks—NoLMHash
    • HKLMSystemCurrentControlSet ControlLSA
    • Prevents Windows from storing LM hash format passwords
    • Susceptible to decryption
    • Key in Windows 2000; value in Windows XP and Server 2003
  • 41. Windows 2000 AS Reg tweaks—NoDefaultExempt
    • HKLMSystemCurrentControlSet ServicesIPSec
    • IPSec normally exempts Kerberos traffic from policy engine
    • Change default so that no traffic is allowed from source port 88
    • See IPSec section for more details
  • 42. Windows 2000 AS Reg tweaks—DisableIPSourceRouting
    • HKLMSystemCurrentControlSet ServicesTcpipParameters
    • Prevents an application from specifying a route in an IP packet
      • Enforces use of computer’s default gateway
    • Eliminates certain man-in-the-middle attacks
  • 43. Windows 2000 AS Reg tweaks—SynAttackProtect
    • HKLMSystemCurrentControlSet ServicesTcpipParameters
    • Limits system resources allocated to incoming requests
    • Prevents certain SYN-flood attacks and denials of service
  • 44. Registry tweaks demo
  • 45. IPSec policies
  • 46. IPSec policies
    • Traffic requirements
      • Web server  SQL Server
      • RAS  management net over L2TP
      • Mgmt server  clients for Terminal Services and file sharing
      • Mgmt server  all servers over private NICs
      • All servers  mgmt server file shares
  • 47. IPSec policies Protection
    • Use digital certificates for authentication
      • Standalone CA taken offline after machine enrollment
    • Signed (SHA-1)
      • Between all computers; enforces machine-to-machine authentication
      • Protects integrity
    • Encrypted (MD5)
      • To/from management server
      • Protects confidentiality of internal traffic if front-end were compromised
  • 48. IPSec policies Policy properties
    • Initial config on all servers
      • Block all IP and all ICMP traffic
    • Web server  SQL Server
      • “ Authenticate and sign” action: IPSec AH
    • Mgmt server  everything
      • “ AuthN, sign, encrypt” action: IPSec ESP+AH
    • Internet  web servers
      • Permit
  • 49. IPSec policies Relationships
  • 50. IPSec UI— each server’s policy demo
  • 51. Remote management and monitoring
  • 52. Remote management
    • An OH requirement is to show it’s possible to update the app during the contest
    • Our solution:
      • L2TP+IPSec remote-access VPN
      • Terminal Services
      • Restricted file shares
  • 53. Remote management L2TP+IPSec remote-access VPNs
    • L2TP is the tunnel; IPSec encrypts it
    • Remote administrator needs—
      • Computer certificate trusted by RRAS server
      • Remote access account credentials
    • Achieve trusted computer and user
      • Computer certificate is non-exportable
        • We know where the user is coming from
      • User account to log on to RRAS (and TS)
        • We know who the user is
  • 54. Remote management Terminal Services
    • Individual accounts on each computer (no domain here)
      • Password strength described later
    • TS access limited to OHTS computer only
    • Carried over the VPN
      • Although TS traffic is already encrypted
    • From OHTS can connect to TS on other computers
      • “Nesting” TS works just fine
  • 55. Remote management File shares
    • “inbox” share
      • To drop off changed site content
      • Write-only
    • “outbox” share
      • To retrieve files for analysis
      • Read-only
  • 56. Remote management Physical network
  • 57. VPN configuration demo
  • 58. SQL Server 2000
  • 59. SQL Server 2000
    • It’s all about reducing the “surface area” exposed to attackers
      • Installed software
      • Authentication
      • Service account
      • Communications protocols
      • Recovery actions
      • Application permissions
  • 60. SQL Server Installed software
    • Service pack 2 and latest security patches
    • Omit—
      • Upgrade tools
      • Debug symbols
      • Replication support
      • Books online
      • Development tools
    • Disable—
      • Msdtc
      • SQL Server agent
      • Microsoft search
  • 61. SQL Server Authentication
    • Modified local security policy to allow NTLMv2 only
    • Configure for Windows only
      • No need to store SA ID/password on web server
    • Set huge SA password
      • In case someone “accidentally” changes authN
    • Set audit level to “Failure”
      • Good evidence of attempted attack forensics
      • But if attacker did figure out password, how would you know…?
        • Maybe should audit success and failure
  • 62. SQL Server Service account
    • Default is LocalSystem
      • Has too many permissions!
    • Create local user account for SQL service
      • Strong password
      • User can’t change
      • No TS access
    • Or can use domain user account if network access is necessary
  • 63. SQL Server A couple others
    • Communications protocol
      • In server network utility: hide SQL Server from client broadcasts
      • Remove named pipes protocol (need TCP/IP only)
    • Recovery actions
      • Set to “restart the service”
      • In service properties page
      • More of a reliability thing…
  • 64. SQL Server Application permissions
    • Delete sample Northwind and Pubs databases
    • Create application database
      • Grant app account permissions on stored procedures but on the tables themselves
      • Prevents execution of ad hoc SQL queries
      • Ensure this account has no permissions anywhere else in SQL Server
  • 65. SQL Server configuration demo
  • 66. Passwords
  • 67. Passwords
    • Do we even need to mention this? ;)
    • Include characters from at least three—
      • Lowercase alphabet
      • Uppercase alphabet
      • Numbers
      • Non-alphanumerics
    • The super-paranoid should use all four plus ALT+??? symbols
    • Go for length
  • 68. Learnings
  • 69. Learnings
    • Every deployment is unique, but certain principles apply everywhere
    • Use, adapt, modify as necessary
    • Need to state the obvious here (after all, this is a PowerPoint presentation…)
  • 70. The obvious
    • Plan for security in the original design
    • Always install latest service packs and patches (design should include plan for this)
    • Always use complex non-intuitive passwords
    • Reduce surface area by disabling unnecessary functionality
    • Adhere to the principle of least privilege
    • Anticipate failure; practice defense in depth
    • Always run IISLockDown and URLScan on IIS
    • Validate all input data
    • Use only parameterized stored procedures on a database
  • 71. © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.

×