How to Hijack a Pizza Delivery Robot with Injection Flaws
•Als PPTX, PDF herunterladen•
1 gefällt mir•568 views
Welcome to the lighter side of the software security world! We’ll explain complex topics like injection flaws, configuration errors, and parameter tampering with real-world analogies, like breaking into your house through your shed, or sneaking into a Coldplay concert using a reflective yellow vest, a walkie talkie toy, and your bravado. If you’ve ever struggled to remember exactly how these issues work or struggled to explain them to someone outside of the security field, this presentation will help (and probably make you laugh). Topics covered include: - Injection Flaws - XSS - SQL Injection - Broken Authentication - Privilege Escalation - Information Disclosure - Parameter Tampering - Configuration Errors This webinar is ideal for anyone who wants to understand core Application Security concepts so they can apply risk mitigation strategies with better context.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie How to Hijack a Pizza Delivery Robot with Injection Flaws
Ähnlich wie How to Hijack a Pizza Delivery Robot with Injection Flaws (20)
Mehr von Security Innovation
Mehr von Security Innovation (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
How to Hijack a Pizza Delivery Robot with Injection Flaws
- 2. About Security Innovation ■ Authority in Software Security – 15+ years research on software vulnerabilities – Security testing methodology adopted by SAP, Symantec, Microsoft and McAfee – Authors of 18 books ■ Helping organizations minimize risk – Assessment: Show me the gaps – Education: Guide me to the right decisions – Standards: Set goals and make it easy and natural ■ Tech-enabled services for both breadth and depth
- 3. What am I doing? ■ I’m going to explain common attack and exploitation techniques, through my power of analogy! ■ There are some great common parallels between computer security and the real world ■ I will gently guide you from the real world into a high-level technical understanding ■ Goal: Lay the groundwork of understanding attacks and vulnerabilities for future
- 5. INJECTION FLAWS Humans + code = sadness
- 6. Pizza Robot Goal: - Deliver pizza - Greet human - Return to pizzeria
- 7. Process 1. Human goes to a website 2. Makes their order 3. Enters their name “Joe” 4. The pizza is made and placed in delivery robot 5. Delivery robot is programmed with commands to get to the house 6. Delivery robot delivers pizza and says “Greetings, Joe” 7. Delivery robot returns to base Forward: 50 ft Turn: Right Forward: 300 ft Turn: Left Forward: 10 ft Turn: Left Forward: 5 ft Greet: Joe Deliver: Pizza Return
- 8. Hijacking a Pizza Robot Forward: 50 ft Turn: Right Forward: 300 ft Turn: Left Forward: 10 ft Turn: Left Forward: 5 ft Greet: Joe Deliver: Pizza Return Expected: Joe Unexpected: Joe Turn: Left Forward: 1 ft Turn: Left Forward: 1 ft Forward: 50 ft Turn: Right Forward: 300 ft Turn: Left Forward: 10 ft Turn: Left Forward: 5 ft Greet: Joe Turn: Left Forward: 1 ft Turn: Left Forward: 1 ft Deliver: Pizza Return
- 9. What’s happening!? ■ Everything in White is “Code” – programmer supplied – Code is simply special text that tells a system what to do – GPS for a computer ■ Everything in Red is “Data” – user supplied – Data is anything else: text, photos, etc. ■ The programmer assumed the name would not include “Code” – Nobody’s named “Turn” or ”Forward” right? ■ When the user supplied those things the robot wrongly interpreted them as “Code” ■ This is fundamentally the same thing that happens in XSS, SQLi, Buffer Overflows, XML injection, and more! Forward: 50 ft Turn: Right Forward: 300 ft Turn: Left Forward: 10 ft Turn: Left Forward: 5 ft Greet: Joe Turn: Left Forward: 1 ft Turn: Left Forward: 1 ft Deliver: Pizza Return
- 10. XSS & SQLI Time to get real
- 11. XSS Mixing code and data in the web browser is confusing
- 12. Cross Site Scripting (XSS) Mixing Code and Data using control characters in the webpage ■ Try this anywhere you control a value on the page – HTML – JavaScript – Headers ■ How is your input being encoded? ■ Test Cases – Change your input – Try <marquee> – Try <script>alert('XSS')</script>
- 13. What CanYou Do with XSS? loginError.action?errorMsg=Sorry%2C+incorrect+username+or+password.
- 14. What CanYou Do with XSS? loginError.action?errorMsg= </div><h1>Login Moved</h1><p>Please Login at: http://evilportal.com</p>
- 15. What CanYou Do with XSS? loginError.action?errorMsg= <marquee>
- 16. What CanYou Do with XSS? loginError.action?errorMsg= <script>document.location='http://evilhacker.or g'</script>
- 17. Why is XSS Possible?
- 18. When is XSS Possible? www.catsearch.com?search=fluffy
- 19. When is XSS Possible? www.catsearch.com?search=sadlfkjsadf...
- 20. When is XSS Possible? www.catsearch.com?search=<script>aler...
- 21. SQL INJECTION Mixing code and data in databases can be catastrophic
- 22. SQL Injection ■ Mixing Code and Data using control characters in DatabaseQueries ■ Try this on any input you think may use the database – Textboxes, URL Parameters, dropdowns, hidden fields ■ Start small, build more complex SQLQueries to manipulate the database ■ Test Cases – Does ' Produce an error message? – Think about how to manipulate the SQL command SELECT * FROM USERS WHERE Username = 'joe' AND Password = 'P4S$
- 23. Logging in with SQL Injection SELECT * FROM USERS WHERE Username = 'joe' AND Password = 'P4S$WorD1'; Username joe Password P4S$WorD1 Commentary: Assuming correct username and password the user is logged in InputValues
- 24. Logging in with SQL Injection SELECT * FROM USERS WHERE Username = 'joe'' AND Password = 'P4S$WorD1'; Username joe' Password P4S$WorD1 com.fjordengineering.store.util.SecureSQLException Commentary: Errant single quote causes a parsing error. Error returned to user. InputValues
- 25. Logging in with SQL Injection SELECT * FROM USERS WHERE Username = 'joe'#' AND Password = 'P4S$WorD1'; Username joe’# Password P4S$WorD1 Login Success: User = joe Commentary: Password check is commented out. Username is checked and attacker is logged in as ‘joe’ InputValues
- 26. Logging in with SQL Injection SELECT * FROM USERS WHERE Username = 'joe' OR 1=1 #' AND Password = 'P4S$WorD1'; Username joe’ OR 1=1 # Password P4S$WorD1 Commentary: Password check is commented out. Username is checked and attacker is logged in as ‘joe’ Everything after the # is disregarded InputValues
- 27. Logging in with SQL Injection SELECT * FROM USERS WHERE Username = 'joe' OR 1=1; Username joe’ OR 1=1 # Password P4S$WorD1 Commentary: Password check is commented out. Username is checked and attacker is logged in as ‘joe’ 1=1 is alwaysTRUE, so we can replace that SELECT * FROM USERS WHERE Username = 'joe' OR TRUE; InputValues
- 28. Logging in with SQL Injection SELECT * FROM USERS WHERE Username = 'joe' OR 1=1; Username joe’ OR 1=1 # Password P4S$WorD1 Commentary: Password check is commented out. Username is checked and attacker is logged in as ‘joe’ Anything ORTRUE is alwaysTRUE SELECT * FROM USERS WHERE Username = 'joe' OR TRUE; SELECT * FROM USERS WHERE TRUE; InputValues
- 29. Logging in with SQL Injection SELECT * FROM USERS WHERE Username = 'joe' OR 1=1; Username joe’ OR 1=1 # Password P4S$WorD1 Commentary: Password check is commented out. Username is checked and attacker is logged in as ‘joe’ OR 1=1 # short circuits the entire where clause in this case SELECT * FROM USERS WHERE Username = 'joe' OR TRUE; SELECT * FROM USERS WHERE TRUE; SELECT * FROM USERS; InputValues
- 30. INJECTION FLAWS ALLOW AN ATTACKERTO INJECT THEIR OWN CODE INTO THE PROGRAM
- 31. BROKEN AUTHENTICATIO N Check ID at the door
- 35. COLDPLAY? I wasn't a big fan of Coldplay before I saw
- 36. Authentication Issues ■ Many opportunities to make mistakes – Default or test credentials – Not storing credentials properly – Forgetting/Resetting passwords – Not protecting authentication tokens properly – Cookie issues – Not handing user input safely – Loss of credentials – Password reuse – Not checking credentials properly – Changing usernames – Phishing – Failure to use 2FA – Overlap with other vulnerabilities (XSS,CSRF,SQLi, etc.) ■ Verify your users ■ Protect their credentials ■ Protect credential equivalents
- 37. PRIVILEGE ESCALATION Can I steal yourTV through your shed?
- 38. I want in here I can get in here
- 39. What’s in a house? ■ TV ■ Computers ■ Electronics ■ Money
- 40. What’s in a shed? ■ Ladders ■ Bolt cutters ■ Spare keys ■ Drills & Saws
- 41. Start Here Go Here
- 42. Horizontal vs.Vertical Escalation ■ Horizontal Privilege Escalation – Allows one user can access another user’s data ■ Vertical Privilege Escalation – Allows a user to increase their privilege level – Anonymous -> User – User -> Manager – Manager –> Administrator
- 43. Authentication is not Authorization Authentication ■ Verify a user is who they say they are ■ Validate that user throughout their use of the system – Through cookies or other tokens Authorization ■ Validate what the user should have access to ■ Users, Roles, access controls, or other methods of authorization Both must be accounted for and fail differently
- 44. INFORMATION DISCLOSURE I bet that guy is in sales, I can tell by his suit
- 45. A guy walks into a bar… Passive - Observe What’s he wearing? Shoes Hair Wedding ring Dirt under fingernails Scars Active - Start a conversation Where are you from? Siblings? How old are you? Pets? Job?
- 46. Computers give away information all the time ■ Hackers gather that information and use it against us every day ■ Tools and Databases scan and collect this information for easy querying ■ Our job is to protect this information
- 47. PARAMETER TAMPERING Control the data Control the future
- 48. Let’s find some deals! ■ Peel off the tags from someWonder Bread ■ Apply tags to fancy bread!
- 50. Everything a computer does starts with input Without input a computer will always do the same thing Input filtering, processing, and blocking sets the stage for everything else
- 51. CONFIGURATIO N ERRORS Don’t put the locks on the wrong side of the door
- 52. Doors, Windows, and Locks Installing a door can be difficult to do securely Installing a window so it locks automatically Don’t forget to lock your doors and windows Did you remember all your doors and windows?
- 54. Many software systems can be configured securely ■ Most software systems don’t come secure by default ■ Insecure use of existing components – The door is installed poorly ■ Insecure configuration of components – The lock is misconfigured ■ Insecure defaults are used – The lock has a reused key or default keycode
- 55. Lots of ways that software can fail ■ Communication is a great first step ■ Start the conversation ■ Make it memorable ■ Give people an anchor of understanding
- 56. ThankYou! Joe Basirico Security Innovation SVP Engineering jbasirico@securityinnovation.com
Hinweis der Redaktion
- Security innovation is a company dedicated to helping our customers with hard application and data security problems. We’ve spent years researching security vulnerabilities, why they occur, what they look like in production code and how to find and fix them. We have experience working with some of the largest companies in a variety of industries - from software companies such as Microsoft to e-commerce companies such as amazon, financial companies and many more. We offer solutions for all phases of the SDLC including instructor led training, computer based eLearning courses, on-site consulting and security assessments as well as technology to help secure sensitive data over the network or at rest. Over the years we’ve analyzed more than 10,000 vulnerabilities both in the course of research studies and through the assessments of software for our customers We got our start as a security testing company, grew to a products and services company that focused on breaking systems (code review, pen test, etc) and then helping fix the problems through secure design and implementation. We acquired NTRU in 2009 to expand our data protection services focused on data in transit as well as data at rest with best in class, high performance cryptography.
- It is important to understand the difference between authentication and authorization. Authentication verifies a user is who they say they are. This is similar to checking an ID card or a passport. Once a user presents their credentials it is common and best practice to provide the user with an authentication token. This is a cryptographically secure random value that maps to the user. The user then presents this token after authentication for authorization. This token should be unique to the user, should expire after a set period of time, should be regenerated after authentication, and should be destroyed client and server side after a timeout or logout event. Authorization validates what the user should have access to. You can think of this as getting a keycard in a building. The keycard may grant you access to certain rooms, but there’s an additional check with each access. Authorization can fail in many different ways as well, including what we call vertical and horizontal authorization issues. Vertical authorization issues occur when an attacker can gain access to a system or asset that a user with a higher privilege controls such as an anonymous attacker gaining user privileges, or a user gaining administration privileges. Horizontal authorization issues occur when the system allows one user to access another user’s data. Authorization can be defined through users, roles, access controls or other methods, but it is critical that those systems are hardened from attack and well implemented. Remember, authentication and authorization are different issues and both must be accounted for in your threat model, architecture and development.