170 likes | 201 Views
Slammer in Depth. James Hamilton Security Architect & Webdata GM jamesrh@microsoft.com Stan Sorensen Director, Product Management stanleys@microsoft.com 2003.02.10. Incidents Reported. CERT/CC incident statistics 1988 through 2002
E N D
Slammer in Depth James Hamilton Security Architect & Webdata GM jamesrh@microsoft.com Stan Sorensen Director, Product Management stanleys@microsoft.com 2003.02.10
Incidents Reported • CERT/CC incident statistics 1988 through 2002 • Incident: single security issue grouping together all impacts of that that issue • Issue: disruption, DOS, loss of data, misuse, damage, loss of confidentiality Source: http://www.cert.org/stats/cert_stats.html
Evolving DB Threat Environment • A decade ago, databases were: • Physically secure • Housed in central data centers – not distributed • External access mediated through customer service reps, purchasing managers, etc. • Security issues rarely reported • Now increasingly DB’s externally accessible: • Suppliers directly connected • Customers directly connected • Customers & partners directly sharing data • Data is most valuable resource in application stack • Value increases with greater integration & aggregation • Opportunities for data theft, modification, or destruction • DB security a growing problem: • We design for & test for high threat public internet scenario • Recommend defense in depth: use firewalls at high value assets
DB Attack Toolkit: Well Armed • Brute force & dictionary-based password crackers • Network sniffers and Port scanners • Object code de-compilers • Quality debuggers • Symbols typically available for problem determination • Application source code not needed for deep attacks • Leveraging cracked systems: • Credentials: leverage & escalate by steps • Compute power: host distributed denial of service • DB Security tools & consulting: • NGSSoftware (http://www.nextgenss.com/) • Internet Security Services (http://www.iss.net/) • Application Security Inc. (http://www.appsecinc.com) • And many others… • Community shared resources: • Exploit, risk, & data sharing the community
Who Cracks DB’s? • Who Cracks DBs? • Black Hats in search of personal gain or system/data damage • Security Professional Services • Individuals in search of fame • We interact with many of these folks • We keep current on new attack vectors & security research • Black hats typically don’t report vulnerabilities • Most attacks not particularly innovative • Vast majority via known & patched vulnerabilities • Most commercial DB security vulnerabilities found in research systems
Slammer History • Port 1434 buffer overrun vulnerability identified: • David Litchfield of NGS Software • Trustworthy Computing (TWC) Security Review (SP3) • MS02-039 Released (07/24/02) • Buffer Overruns in SQL Server 2000 Resolution Service Could Enable Code Execution • Fixes Port 1434 vulnerability exploited by Slammer • NGS Website posting (07/25/02) • Black Hat Conference 2002 (07/31/02-08/01/02) • David Litchfield presentation • MS02-061 Released (10/16/02) • Elevation of Privilege in SQL Server Web Tasks • Recommended SP2 patch level (recommend SP3 after testing) • SQL Server 2000 SP3 Released (01/17/03) • TWC security review improvements • External reported issues • Slammer (01/25/03)
Slammer Overview • Slammer re-using existing ideas: • "The Slammer code is a straight cut-and-paste job" – D. Litchfield • Most attacks exploit known vulnerabilities • Recent SQL Server Service Levels unaffected • Single UDP packet delivery very effective • Spread doubles every 8.5 seconds • 90% of vulnerable computers in 10 min • Max rate hit 55 million scans/second • 74,855 systems affected in one minute
DB Attack: Buffer Overrun Exploits Previous function’s stack frame • x86 stacks grow downward • Buffer overrun on stack can rewrite: • Return address • Frame pointer • EH frame • Exploit usually involves privilege escalation Function arguments Return address Frame pointer EH frame Local variables andlocally declaredbuffers Callee saveregisters Garbage
Slammer Operation • Initialization: • Patch payload • Own code gets stepped on prior to gaining control • Needed to send a clean copy of itself in attack loop • Gets address of GetProcAddress & Loadlibrary • From the Import Address Table in sqlsort.dll • Note SQLSort IAT address is hardcoded • Obtains library base addresses & function entry points • Calls gettickcount (used as pseudo-random seed) • Creates a UDP socket (UDP is connection free) • Loop • Generate pseudo-random 32bit number to use as IP address • Send payload (its own memory image) to random IP address • 376 bytes ... fits in single UDP packet • no flow control on UDP • Central loop is 22 Intel machine instructions • GOTO Loop Quality Disassembly: http://www.eeye.com/html/Research/Flash/sapphire.txt
Security Response Tools • SQL Server Scan • Scans computer, domain, or IP range • Finds vulnerable SQL Server 2000 & MSDE 2000 instances • Displays versions & patch data • Under NT4.0, Windows 2000, or Windows XP it stops & disables vulnerable instances of SQL Server • SQL Check • Runs on a single system • Lists SQL Server Instances & patch levels on all SQL Server supported operating systems • Shuts down & disables vulnerable SQL Server instances under Windows NT4, Windows 2000, and Windows XP • SQL Critical Update • Runs on a single system • Applies security patch to all vulnerable SQL 2000 and MSDE 2000 instances • Targeted Slammer security patch for SQL 2000 RTM, SP1, & SP2 in a single tool • SMS Deployment tool • SMS script to deploy SQL Critical Update
Security Design Principles • Secure by Design • Secure and robust code • Threat analysis and testing • Secure by Default • Default configuration is a secure system • Discourage insecure configurations • Minimize attack surface • Install only necessary components • Secure by Deployment • Principle of least privilege • Grant minimal permission required to function • Low privileged service accounts • Automate / Assist software maintenance • Good tools for security assessment / admin 2002 Focus Emphasizing Secure Engineering 2003 Focus Emphasizing Secure Default & Deployment
2002 Security Focus • Strong engineering practices • Engineer education, threat models, secure feature designs, secure by default, threat models, security code reviews, security focused dev tools, & security part of overall dev process • Entire SQL Server team for full 3 months • Release vehicles: SP3 & Yukon • Concise customer communications • Security bulletins (www.microsoft.com/security) • Clear security severity classification adopted • Easy patch installation • SQL Server hotfix installer • Microsoft Baseline Security Advisor • Checks for latest patch levels & secure config
2003 Security Focus • Productize & generalize Slammer response tools • Locating installs & product inventory • Ease of mass patch installation • Windows Update & Software Update Service effective for distributing Windows components • General Microsoft patch distribution mechanism planned that will include SQL Server • Emergency response procedures in-place • Simple security-focused documentation • Including scenarios & how to safely deploy • Yukon Security features: • Fine grained access control • Domain-wide password policy enforcement • Fine grained deployment control • Only needed features installed & on by default • Metadata security • User/Schema separation
Summary • Computer security attacks growing exponentially • Database & backend systems are under threat • Attackers are well armed & growing in numbers • SQL Server responding aggressively • Working closely with security experts both internal & external • Fully 25% of 2002 development budget targeted directly on security • Continued focus on security with clear deliverables through 2003 • Key focus for 2003: • Improved documentation • Deployment tools to ease finding & hot fixing • Fine-grained deployment control • Security features for more precise & simpler admin