Basics of Secure Design Development and Test Secure
Basics of Secure Design, Development, and Test Secure software made easier <Date> <Presenter>
Motivation • In this course, we will: – Look at the Microsoft Security Development Lifecycle (SDL) – Briefly review some secure design, development, and test concepts – Explore the security issues that arise if these design, coding, and test principles are not properly applied • This will provide you with information that you can use to make your software more secure
Agenda • • • Microsoft Security Development Lifecycle (SDL) overview Module 1: Secure Design – Attack Surface Reduction – Threat Modeling Module 2: Secure Development – – – – • Buffer overflows Integer arithmetic errors Canonicalization issues Managed Code: Cross-site scripting (XSS) Managed Code: SQL injection Cryptography Code Review Module 3: Security Testing – Fuzz Testing
Microsoft Security Development Lifecycle (SDL)
Working to protect our users… Education Administer and track security training Process Guide product teams to meet SDL requirements Accountability Establish release criteria and sign-off as part of FSR Ongoing Process Improvements Incident Response (MSRC)
Very Encouraging Results! Total Vulnerabilities Disclosed 12 Months After Release Total Vulnerabilities Disclosed 36 Months After Release 187 400 242 119 157 66 34 3 Windows® XP Before SDL Windows Vista® After SDL 45% reduction in Vulnerabilities OS III SQL Server® 2000 Before SDL SQL Server 2005 Competing commercial DB After SDL 91% reduction in Vulnerabilities Consistent application of sound security practices during all phases of a development project will result in fewer vulnerabilities
Still Much to Be Done: The Pain of "Blaster" • • Two lines of C code in RPCSS • Led to while (*pwsz. Temp != L'\') *pwsz. Server. Name++ = *pwsz. Temp++; – >1, 500, 000 infected computers – 3, 370, 000 Product Support Services (PSS) calls in September 2003 (normal virus volume is 350, 000) – Plenty of negative commentary • " This [is] going to raise the level of frustration to the point where a lot of organizations will seriously contemplate alternatives to Microsoft" Gartner • "There's definitely caution warranted here. [Microsoft's security] efforts were sincere, but I am not sure if they were sincere enough" Forrester
The Horrible Truth • No matter how much effort we expend, we will never get code 100 percent correct – This is an asymmetric problem • We must be 100 percent correct, 100 percent of the time, on a schedule, with limited resources, only knowing what we know today – Oh, and the product has to be reliable, supportable, compatible, manageable, affordable, accessible, usable, global, doable, deployable… • They can spend as long as they like to find one bug, with the benefit of future research • • We’re human and our tools are far from perfect There’s still a business case for improving security now
The Horrible Truth (continued) • • Tools make it easy to build exploit code Reverse engineering tools • Structural Comparison of Executable Objects, Halvar Flake – http: //www. zynamics. com/downloads/dimva_paper 2. pdf – PCT Bug: "Detecting and understanding the vulnerability took less than 30 minutes" – H. 323 ASN. 1 Bug: "The total analysis took less than three hours time" • Exploit payloads • www. metasploit. com
Choose your ‘sploit Enter some details… Here’s the ‘sploit code!
The Horrible Truth (concluded) • • Don't be a statistic: A worm or serious vulnerability in any major product can have devastating impact to you and your users In general: – Cost for attacker to build attack is very low – Cost to your users is very high – Cost of reacting is higher than cost of defending
Module 1: Secure Design
Module 1: Secure Design Attack Surface Reduction (ASR)
The Attack Surface Reduction Process • Look at all of your entry points – Network I/O – File I/O • Rank them – – Authenticated versus anonymous Administrator only versus user Network versus local UDP versus TCP
Watch Out for Fanout! File formats −For example, JPG, MSH, or GIF Verbs −HTTP • Classic GET, POST, HEAD, DELETE • Web. DAV Subprotocols −SSL 2, SSL 3, TLS, PCT −SMTP PROPPATCH, PROPFIND, MOVE, LOCK • HELO, EHLO, MAIL, RCPT −Queries • Extended sprocs and sprocs
It’s Not Just About Turning Stuff Off! Higher Attack Surface Lower Attack Surface Executing by default Off by default Open socket Closed socket UDP TCP Anonymous access Authenticated access Constantly on Intermittently on Admin access User access Internet access Local subnet access SYSTEM Not SYSTEM! Uniform defaults User-chosen settings Large code Small code Weak ACLs Strong ACLs
ASR Examples Windows − Authenticated RPC − Firewall on by default Internet Information Services version 6 (IIS 6) − Off by default − Network service by default − Static files by default SQL Server 2005 − xp_cmdshell off by default − CLR and COM off by default − Network service Visual Studio® 2005 − Web server localhost only − SQL Server Express localhost only
Attack Surface Reduction is as important as trying to get the code right
Module 1: Secure Design Threat Modeling
Threat Analysis • • • Secure software starts with understanding the threats Threats are not vulnerabilities Threats live forever; they are the attacker's goal Mitigation Attacker Threat Vulnerability
The Process in a Nutshell Vision Model Identify Threats Validate Mitigate
Whiteboard Your Architecture • Start with person, processes, data flows, data stores – Unique shape per item – Data flows should be one way each – Label them with data, not read/write • • Draw attack surfaces/trust boundaries Tell a story to see if your picture is ok External Entity • People • Other systems • Microsoft. com Process • DLLs • EXEs • COM object • Components • Services • Web Services • Assemblies Data Flow • Function call • Network traffic • Remote Procedure Call (RPC) Data Store • Database • File • Registry • Shared Memory • Queue / Stack Trust Boundary • Process Boundary • File system
Find Threats: Use STRIDE per Element • Start with items connected to dangerous data flows (those crossing boundaries) • • Use the chart to help you think of attacks Keep a running list S External Entity P Process P Data Store Data Flow T R I D E P P P P
Understanding the STRIDE Threats Threat Property Definition Example Spoofing Authentication Pretending to be any of billg, microsoft. com or ntdll. dll Tampering Integrity Impersonating something or someone else. Modifying data or code Repudiation Non-repudiation Claiming to have not performed an action. Information Confidentiality Exposing information to someone not authorized to see it Deny or degrade service to users “I didn’t send that email, ” “I didn’t modify that file, ” “I certainly didn’t visit that web site, dear!” Allowing someone to read the Windows source code; publishing a list of customers to a web site. Crashing Windows or a web site, sending a packet and absorbing seconds of CPU time, or routing packets into a black hole. Disclosure Denial of Service Availability Elevation of Authorization Privilege Gain capabilities without proper authorization Modifying a DLL on disk or DVD, or a packet as it traverses the LAN. Allowing a remote internet user to run commands is the classic example, but going from a limited user to admin is also Eo. P.
Mitigation Techniques Threat Mitigation Feature Spoofing Authentication Tampering Integrity Repudiation Nonrepudiation Information Disclosure Confidentiality Denial of Service Availability Elevation of Privilege Authorization
Mitigating Your Threats • For each threat, decide how to stop it – – • Redesign and eliminate Use standard threat mitigations Invent new mitigation (not recommended!—seek help) Accept risk in accordance with SDL bug bar File a work item in your bug tracking DB – Treat threats as bugs, mitigations as features
Validate • Check threat model diagrams – Do they match the design docs or code? • Check your bug DB work items are all – Closed as completed – QA’d
Context Diagram Services for Macintosh
Diagrams Should Not Resemble • • • Flow charts Class diagrams Call graphs
Determining Threat Types TID SR 5. 0 TID 1. 0 STRIDE TID 7. 0 TID 8. 0 10. 0 SR 6. 0 STRIDE 2. 0. 11. 0 TID 9. 0 4. 0 3. 0 STRIDE TID Each element in the Data Flow Diagram (DFD) is susceptible to one or more threat types
DFD Elements Are Threat Targets: A “Work List” Data Flow S T R I D 1 5 5 6 6 7 7 8 P P P Data Store 7 9 11 P P P P P Interactor 1 2 8 P Process 3 4 5 6 10 P P P E Each is a potential threat to the system Each threat is governed by the conditions which make threat possible P P P P P
A Special Note About Information Disclosure Threats All information disclosure threats are potential privacy issues Is the data sensitive or PII?
Call to Action • Threat model something – Like your program! – If you’re stuck, threat model a different program • • • Go breadth-first Have fun Seek more intensive training – "Introduction to Threat Modeling"
Threat M odel Che cklist þ No design is complet model! e withou t a threa þ Follow t anonym ous data þ Every paths threat ne eds a sec þ Check urity tes all inform t plan are they ation dis privacy i c ssues? losure threats – threat softwa re vuln
Summary • • Defined the SDL • Explained the importance of threat models and described the use of DFDs and threat trees during the threat modeling process Described the Attack Surface Reduction process with some examples of its positive impact
Question 1: Which of the following is an example of low attack surface? A. User-controlled settings B. Weak ACLs C. Internet access
Question 2: Information disclosure is caused by a breach of…? A. Privacy B. Security C. Both
Question 3: Which mitigation technique can be used to protect against the STRIDE spoofing threat? A. Integrity B. Authentication C. Availability D. Authorization
Module 2: Secure Development
Module 2: Secure Development Buffer Overflows
What Are Buffer Overflows (BOs)? • • External data is larger than the destination Overflowing the destination tramples some sensitive, in-memory construct that determines execution flow – Causing the application to change execution flow – To the attacker’s code that is included in the data • • • Cause: Trusting input C/C++ code the most common victim Direct access to memory
Stack Buffer Overflows at Work All determine execution flow Exception Handlers Function Pointers Virtual Methods Function return address Buffers ! d 3 n 0 w Other vars EBP EIP Args void func(char *p, int i) { int j = 0; CFoo foo; int (*fp)(int) = &func; char b[128]; strcpy(b, p); } Bad things happen if *p points to data longer than b
Buffer Overflow Examples SQL Server Instance Resolution (MS 02 -039) #define INSTREGKEY "SOFTWARE\Microsoft SQL Server\" #define MAX_RECV_MSG 256 void Ssrp. Svr(LPSTR sz. Instance. Name) { BYTE rgb. Recv. Buf[MAX_RECV_MSG]; . . . ssrp. Msg = Ssrp. Recv. Msg(rgb. Recv. Buf); switch(ssrp. Msg) { case CLNT_UCAST_INST: // Verb #4 Ssrp. Enum((LPSTR)&rgb. Recv. Buf[1]); } Sitting on port 1434—The Internet SSRPMSGTYPE Ssrp. Recv. Msg(BYTE * rgb. Recv. Buf) {. . . bytes. Recd = recvfrom( g. Svr. Sock, (char*) rgb. Recv. Buf, MAX_RECV_MSG, 0, (SOCKADDR *)&gclient. Addr, &c. Client. Addr ); return((SSRPMSGTYPE)rgb. Recv. Buf[0]); } Read no more than 256 bytes from the network BOOL Ssrp. Enum(LPSTR sz. Inst. Name, . . . ) { char szreg. Version[128]; sprintf(szreg. Version, "%s%s\MSSQLServer\Current. Version", INSTREGKEY, sz. Inst. Name); Then copy into a 128 -byte buffer
Heap Overflows at Work Write a DWORD anywhere in memory when block is free()’d Heap Block d! 3 n w 0 Heap Block Pointer to prior block A 1 Pointer to next block D 1 A 2 D 2 On block free: D 1 [A 1] D 2 [A 2]
Zotob (Pn. P Code) CONFIGRET Sitting on port 445— Res. Des. To. Nt. Resource( IN PCVOID Resource. Data, the Internet IN RESOURCEID Resource. Type, IN ULONG Resource. Len , IN PCM_PARTIAL_RESOURCE_DESCRIPTOR p. Res. Des , IN ULONG ul. Tag ) { case Res. Type_Class. Specific: { PCS_RESOURCE p. Cs. Data = (PCS_RESOURCE)Resource. Data; LPBYTE ptr = NULL; ptr = (LPBYTE)((LPBYTE)p. Res. Des + sizeof(CM_PARTIAL_RESOURCE_DESCRIPTOR)); memcpy(ptr, p. Cs. Data->CS_Header. CSD_Signature + p. Cs. Data->CS_Header. CSD_Legacy. Data. Offset, p. Cs. Data->CS_Header. CSD_Legacy. Data. Size ); Amount of data to copy is controlled by the attacker
The 'n'-Functions Are Safe? Right? ! // Example #1 (code verifies psz. Src is <= 50 chars) #define MAX (50) char *psz. Dest = malloc(sizeof(psz. Src)); strncpy(psz. Dest, psz. Src, MAX); sizeof is 4 bytes, not 50 String not null-terminated if len(psz. Src) >= MAX // Example #2 #define MAX (50) char sz. Dest[MAX]; strncpy(sz. Dest, psz. Src, MAX); // Example #3 #define MAX (50) Wrong buffer size! char sz. Dest[MAX]; strncpy(sz. Dest, psz. Src, strlen(psz. Src)) ;
The 'n'-Functions Are Safe? Right? ! // Example #4 Wrote NULL to element #define MAX (50) 51, not 50! char sz. Dest[MAX]; strncpy(sz. Dest, psz. Src, MAX); psz. Dest[MAX] = '