Fundamentals of Secure Development

2. Fundamentals of Secure Development Dave Weinstein Security Development Engineer Microsoft

3. What is Secure Development? A process, not a magic bullet or secret technology

4. What is Secure Development? • Security Development Lifecycle • Secure by Design • If you add security as an afterthought, it is just an afterthought • Secure by Default • The default configuration should be secure; normal users should not have to go searching through options to lock things down • Secure in Deployment • Provide tools and guidance for securing the application, and a solid and easy patch and update path • Communications • Be prepared for the discovery of vulnerabilities and communicate openly and responsibly with end users and/or administrators to help them take protective action SD3+C

5. What could a major exploited vulnerability mean? • If player run servers are vulnerable… • No one will host games • If clients searching for games are vulnerable… • No one will play games • If clients in a game with a malicious client are vulnerable… • No one will play with strangers • If replays, save games, or mods are vulnerable… • The community may die • If your game is vulnerable… • The franchise may die

6. Myths and Misperceptions about Security

7. Myths and Misperceptions • People writing malicious code are doing it to prove they can • People writing malicious code are doing it primarily for the money. Stolen identities, botnets, stolen credit card information, and so on. • The security research community, on the other hand, has a great many people who investigate security issues because they find it interesting. Conflating the researchers who tell you about security violations with the bad guys who exploit them is another example of misperception.

8. Myths and Misperceptions • This is an operating system issue, not an application issue. • As operating systems become hardened, the attacks are moving up the application stack. Malware has been found in the wild exploiting instant message clients and audio players. Success in the mass market makes you a target.

9. Myths and Misperceptions • This isn’t important enough to miss a ship date for • “Market seems to act on this information and punishes a vendor, who on an average, loses around 0.63% of its market value on the day a vulnerability is reported in its products.” • [Telang R and S Wattal (2004)]

10. The most important thing to realize… Data is evil (Validated Data is only mostly evil)

11. Why Data is Evil • Data affects code execution. If you didn’t change software behavior based on the data, you wouldn’t be loading it at all. • Software which naively trusts data from outside sources is easy prey • Without training programmers defend against bugs during development, not against deliberately malformed data in the real world • Even with training, simple mistakes can and will happen

12. Why Data is Evil • Small errors can have devastating results • while (*pwszTemp != L'\\') *pwszServerName++ = *pwszTemp++; • Blaster involved more than 1.5 million compromised computers, all from a two line coding error.

13. Why Data is Evil • Data types are not as safe as you think they are • Image based vulnerabilities that can result in remote execution of code have been found on all major operating systems and across the application stack.

14. Code Vulnerability:Bad APIs

15. Code Vulnerability: Bad APIs • There are classes of functions which are commonly misused, and are extremely prone to security vulnerabilities. • strcpy() • strncpy() • sprintf() • …

16. Code Vulnerability: Bad APIs • Buffer constants are often subject to change, and the information isn’t necessarily propogated across the code: • … • fgets( buffer, 256, file ); • LogCommand( users[curUser].Name, buffer ); • … void LogCommand( char *user, char *cmd ) { char logString[128]; sprintf( logString, “User: %s Command: %s”, user, cmd ); … }

17. Code Vulnerability: Bad APIs • What about the “n” functions? • // Code verifies pszSrc is <= 50 chars • #define MAX (50) • char *pszDest = malloc(sizeof(pszSrc)); • strncpy(pszDest,pszSrc,MAX); • Human error: sizeof is 4 bytes, not 50

18. Code Vulnerability: Bad APIs • What about the “n” functions? • #define MAX (50)char szDest[MAX]; • strncpy(szDest,pszSrc,MAX); • Latent error: The string not null-terminatedif len(pszSrc) >= MAX

19. Code Vulnerability: Bad APIs • What about the “n” functions? • #define MAX (50)char szDest[MAX]; • strncpy(szDest,pszSrc,strlen(pszSrc)); • Human Error: The limiting size is derived from the source buffer, instead of the destination

20. Attacks:An Introduction to the STRIDE Taxonomy

21. STRIDE: Spoofing • What it is: • Impersonating a person or machine • What it can gain: • Anything that the impersonated entity can do • Countermeasures: • Authentication

22. STRIDE: Spoofing • Identification • Who someone claims to be • Authentication • Proof as to their claim of identity • Authorization • Proof of their ability to do something • Do not mistake identification for authentication, or authentication for authorization

23. STRIDE: Spoofing • Example: SSL Certificates • An SSL certificate for a web site will confirm that you are talking to the web site the certificate was issued for. • This means that you were not subject to DNS poisoning, or other means of redirection • It does NOT mean that the web site the certificate was issued for is the web site you SHOULD be talking to. Authentication is not authorization.

24. STRIDE: Spoofing • Types of authentication • Something you are • Something you have • Something you know • Username / Password • Single factor authentication • Smartcard / PIN • Two factor authentication

25. STRIDE: Tampering • What it is: • Altering data or data flows • What it can gain: • Injection of false or malicious data • Countermeasures: • Integrity Checking • Integrity checking and prevention of Information Disclosure are the focus of the Cryptography portion of this presentation

26. STRIDE: Repudiation • What it is: • Denying that an action or transaction took place • What it can gain: • Avoiding the consequences of an action • Countermeasures: • “Non-repudiation services generate evidence which will convince a disinterested party that a specific subject performed a specific action”

27. STRIDE: Repudiation • Repudiation attacks • Primarily involve people making claims, not software issues • Can be escalated in some cases to entities outside the developer or publisher • Credit card companies • Legal System

28. STRIDE: Information Disclosure • What it is: • Gaining access to information that should not be available to the attacker • What it can gain: • Passwords, account information, personally identifiable information… • Countermeasures: • Confidentiality • Encryption

29. STRIDE: Denial of Service • What it is: • Stopping a service or system from running • What it can gain: • Revenge for perceived slights • The ability to leave a game without “quitting” • Blackmail • Countermeasures: • Availability • Robustness

30. STRIDE: Elevation of Privilege • What it is: • Using one level of privilege to gain a higher level • What it can gain: • All the capabilities of the higher level of privilege • Countermeasures: • Authorization

31. STRIDE: Elevation of Privilege • Remote execution of code by an unauthenticated user is the ultimate Elevation of Privilege. • This is the goal of an attacker. • UDP sockets that are listening on the Internet are particularly vulnerable.

32. STRIDE: Elevation of Privilege • Additional Note: Software should run with the smallest set of privileges possible. There is no reason that a game should require high level privileges to run. • The answer to people trying to break into a building is not to remove the locks. Or the doors.

33. Code Vulnerability:Format Strings

34. Code Vulnerability:Format Strings • What is wrong with this? … char buffer[256]; if( strlen( description ) < 256 ) { sprintf( buffer, description ); } … What happens if description consists of “%u%u%u%u%u%...”?

35. An Introduction to Attack Surfaces and Threat Modeling

36. Attack Surface • The attack surface of an application is the set of sources of data it accepts. Anything that is providing you with data externally is a potential attack vector. • Game traffic • Matchmaking traffic • Voice traffic • Player provided skins and icons • Player created maps • Game mods • Replays

37. Attack Surface • A code defect is not a vulnerability unless there is an open attack surface that lets an attacker provide data to it. • However, do not patch a vulnerability by simply putting guard code in the discovered attack surface. There are powerful binary analysis tools available that make it trivial to determine the changes in the code. By only providing a work around for the initially discovered attack surface, you make it easy for attackers to isolate the vulnerable component and trace other surfaces that may provide access to it.

38. Threat Modeling • Data becomes interesting when it crosses “trust boundaries”. • Trust boundaries occur whenever you cross machines, users, privilege levels, or authors. • Loading the official missions • Loading a player created map • Loading a player created mod • Playing a multiplayer game • Viewing a replay in engine • Viewing a replay from another user in engine

39. Threat Modeling • Threat models describe the way the data flows across the application, and highlight where the trust boundaries are crossed. • You can consider the threat model to be a profiler indicating where you should concentrate your efforts in securing the application.

40. Function call • Network traffic • Shared memory • Etc… • Services • Web Services • Assemblies • DLLs • EXEs • COM object • Etc… • Database • File • Registry • Shared Memory • Queue/Stack • etc… • Real People • News feeds • Data feeds • Events • Notifications • Etc… Threat Modeling:Data Flow Diagrams

41. FPS: Context Diagram Leaderboard Client Master Server List Local Player Game Service Player Rankings Server Local Player Remote Server Admin

42. FPS: Partial DFD Level 0 Client Leaderboard Report Servers List Servers Report Leaders Master Server List Request Server List Request Server List Update Server List Game Service Get Rankings Report Game Player Rankings Server Update Rankings Report Score

43. FPS: Partial DFD Level 0 Change Settings Game Settings Transfer Mods/Maps Client Get Settings Report Settings Update Game State Assets Default Game Assets Report Actions Server Player Created Maps Maps Report Settings Change Settings Player Created Mods Changed Game Functionality Manage Players Remote Server Admin

44. External Entity Data Store Dataflow Reference: Primary Threat Chart By Asset S T R I D E X X X X X X X X Process X X X X X X X

45. Code Vulnerability:ASSERT

46. Code Vulnerability:ASSERT Considered Harmful void Packet::CopyContents( void *buffer, unsigned int maxSize ) { ASSERT (buffer ); ASSERT( ContentsSize() <= maxSize ); memcpy( buffer, Contents(), ContentsSize() ); }

47. Code Vulnerability:ASSERT Considered Harmful • What ASSERT is good for? • Checking for coding errors within the same trust level • Checking for code integration defects • Finding cases where the assumptions of one part of the code base have been changed • When is ASSERT dangerous? • When it is used to validate untrusted data sources

48. A (Very) Basic Introduction to Cryptography

49. Basic Introduction to Cryptography • Cryptography is not a simple subject • Even using Cryptography effectively is not a simple subject • Unless you are a skilled cryptographer, and you present your findings publicly, and they hold up over years of analysis, using cryptographic techniques you invented is at best only a bad idea...

50. Basic Introduction to Cryptography • At the most basic, cryptography involves secrets; some combination of things that one or all parties involved know, but that no one else does • How effective cryptography is depends on the strength of the secrets, the way in which they are used, and the state of current technology.