1 / 71

Surviving OpenHack 4

Surviving OpenHack 4. Steve Riley and Timothy Bollefer Microsoft Corporation. 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

imelda
Télécharger la présentation

Surviving OpenHack 4

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SurvivingOpenHack 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 applicationUser authentication • ASP.NET provides many options • Integrated Windows authentication • Basic • Digest • .NET Passport • Client certificate • Forms (custom) • eWeek requested forms

  7. Web applicationForms 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 applicationPage 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 applicationPage protection—request authN <authentication mode="Forms"> <forms loginUrl="Login.aspx" name="OPSAMPLEAPP"/> </authentication>

  10. Web applicationPage protection—required authN <?xml version="1.0" encoding="utf-8" ?> <configuration> <system.web> <authorization> <deny users="?" /> </authorization> </system.web> </configuration>

  11. demo Web.config files

  12. Web applicationAccount 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 applicationInput 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 applicationInput 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 applicationInput validation—1st 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 applicationInput validation—2nd check • Parse URL query string • System.Text.RegularExpressions.Regex • Validate input with regular expression • Allow numbers only Regex isNumber = new Regex("^[0-9]+$"); if(isNumber.Match(inputData) ) { // use it } else { //discard it }

  17. Web applicationInput validation—3rd 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 applicationInput validation—4th 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. demo Input validation code

  20. Web applicationStoring secrets • Need to protect two kinds here • Database connection/login string • User password and credit card information • Use different approaches for each

  21. Web applicationStoring 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 applicationStoring 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 applicationStoring 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 applicationStoring 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. demo Code forstoring secrets

  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.0Default 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.0IISLockDown • 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.0Remove 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.0Account 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%\temp: 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.0URLScan • 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.0Folder 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. demo IISLockDownExtension remappingAccountsURLScanFolder/log ACLs

  36. Windows 2000 Advanced Server

  37. Windows 2000 AS • Updated service packs and security patches • Disable unused OS services • Various registry-based tightenings

  38. Alerter Appmgmt Bits Browser Clipsrv Dfs Dhcp Fax Ismserv Kdc Windows 2000 ASUnused services 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 ASUnused 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 ASReg tweaks—NoLMHash HKLM\System\CurrentControlSet\Control\LSA • 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 ASReg tweaks—NoDefaultExempt HKLM\System\CurrentControlSet\Services\IPSec • 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 ASReg tweaks—DisableIPSourceRouting HKLM\System\CurrentControlSet\Services\Tcpip\Parameters • 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 ASReg tweaks—SynAttackProtect HKLM\System\CurrentControlSet\Services\Tcpip\Parameters • Limits system resources allocated to incoming requests • Prevents certain SYN-flood attacks and denials of service

  44. demo Registry tweaks

  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 policiesProtection • 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 policiesPolicy 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 policiesRelationships

  50. demo IPSec UI—each server’s policy

More Related