Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

An Attacker's View of Serverless and GraphQL Apps - Abhay Bhargav - AppSec California 2019

607 views

Published on

Serverless Technology (Functions as a Service) is fast becoming the next "big thing" in the world of distributed applications. Organizations are investing a great deal of resources in this technology as a force-multiplier, cost-saver and ops-simplification cure-all. Especially with widespread support from cloud vendors, this technology is going to only become more influential. However, like everything else, Serverless apps are subject to a a wide variety of attack possibilities, ranging from attacks against access control tech like Function Event Injection, JWTs, to NoSQL Injection, to exploits against the apps themselves (deserialization, etc) escalating privileges to other cloud component.

On the other hand GraphQL (API Query Language) is the natural companion to serverless apps, where traditional REST APIs are replaced with GraphQL to provide greater flexibility, greater query parameterization and speed. GraphQL is slowly negating the need for REST APIs from being developed. Combined with Serverless tech/Reactive Front-end frameworks, GraphQL is very powerful for distributed apps. However, GraphQL can be abused with a variety of attacks including but not limited to Injection Attacks, Nested Resource Exhaustion attacks, Authorization Flaws among others.

This talk presents a red-team perspective of the various ways in which testers can discover and exploit serverless and/or GraphQL driven applications to compromise sensitive information, and gain a deeper foothold into database services, IAM services and other other cloud components. The talk will have some demos that will demonstrate practical attacks and attack possibilities against Serverless and GraphQL applications.

Published in: Technology
  • Be the first to comment

An Attacker's View of Serverless and GraphQL Apps - Abhay Bhargav - AppSec California 2019

  1. 1. An Attacker’s View of Serverless and GraphQL Abhay Bhargav - we45 Copyright - we45, 2019 abhaybhargav
  2. 2. abhaybhargav Yours Truly • Founder @ we45 • Chief Architect - Orchestron • Avid Pythonista and AppSec Automation Junkie • Speaker at DEF CON, BlackHat, OWASP Events, etc world-wide • Lead Trainer - we45 Training and Workshops • Co-author of Secure Java For Web Application Development • Author of PCI Compliance: A Definitive Guide Copyright - we45, 2019
  3. 3. abhaybhargav Copyright - we45, 2018
  4. 4. abhaybhargav Get ready! Copyright - we45, 2018
  5. 5. abhaybhargav Get ready! Copyright - we45, 2018
  6. 6. abhaybhargav Get ready! Copyright - we45, 2018
  7. 7. abhaybhargav Today’s Session • A Gentle Introduction to Serverless (FaaS) and GraphQL • Attacker’s view of FaaS • Attacker’s View of GraphQL • Demos • FIN Copyright - we45, 2018
  8. 8. abhaybhargav As always, I pray to the demo gods! Copyright - we45, 2018
  9. 9. abhaybhargav Serverless (FaaS)
  10. 10. abhaybhargav Moving FaaSter! Copyright - we45, 2018 Monolith Microservice Function
  11. 11. abhaybhargav What is FaaS? Copyright - we45, 2018
  12. 12. abhaybhargav What is FaaS? • Functions that are triggered via events => Triggering a Container/VM Copyright - we45, 2018
  13. 13. abhaybhargav What is FaaS? • Functions that are triggered via events => Triggering a Container/VM • Execute (thing) Copyright - we45, 2018
  14. 14. abhaybhargav What is FaaS? • Functions that are triggered via events => Triggering a Container/VM • Execute (thing) • The container/VM freezes post execution and kills Copyright - we45, 2018
  15. 15. abhaybhargav What is FaaS? • Functions that are triggered via events => Triggering a Container/VM • Execute (thing) • The container/VM freezes post execution and kills • Repeat Copyright - we45, 2018
  16. 16. abhaybhargav Summary Copyright - we45, 2018 Function •Short lived •No ports •No state •Single purpose
  17. 17. abhaybhargav Events Copyright - we45, 2018
  18. 18. abhaybhargav Lifecycle Copyright - we45, 2018 Containers/MicroVMs are “thawed” when they are invoked again Additional Containers/MicroVMs are spawned based on concurrent invocations Function is invoked launching a container to run. Destroyed after. Deploy into Lambda with zip file
  19. 19. abhaybhargav customary FaaS Demo…
  20. 20. abhaybhargav GraphQL
  21. 21. What is GraphQL? • API Query Language => instead of REST API • (Usually) single endpoint to query and insert (mutate) data for the API • Query/Mutate exactly what you want • Multiple Resources in a Single Request • PubSub Functionality for Realtime Data
  22. 22. REST vs GraphQL
  23. 23. REST vs GraphQL re_path(r'^media/(?P<path>.*)$', MediaServeView.as_view()), re_path(r'^api/user/password/change/(?P<email>.*)/$', UserUtilityView.as_view({'post':'change_password'})), re_path(r'^api/user/token/', obtain_jwt_token), re_path(r'^api/user/profile/', UserProfileView.as_view()), re_path(r'^api/users/list/$', UserListView.as_view({'get':'list'}),name='user_list'), re_path(r'^api/organizations/list/$', OrganizationListView.as_view({'get':'list'}),name='org_list'), re_path(r'^api/projects/list/$', ProjectListView.as_view({'get':'list'}),name='pro_list'), re_path(r'^api/applications/list/$', ApplicationListView.as_view({'get':'list'}),name='app_list'), re_path(r'^api/users/$', UserView.as_view({'get':'list','put':'create'}),name='user'), re_path(r'^api/users/(?P<pk>d+)/$', UserView.as_view({'get':'retrieve','post':'update','delete':'destroy'}),name='ind_user'), re_path(r'^api/tools/$', OptionsListView.as_view({'get':'tools'}),name='tools'), re_path(r'^api/hosttypes/$', OptionsListView.as_view({'get':'hosttypes'}),name='hosttypes'), re_path(r'^api/platforms/$', OptionsListView.as_view({'get':'platforms'}),name='platforms'), re_path(r'^api/permissions/$', OptionsListView.as_view({'get':'permissions'}),name='permissions'),
  24. 24. GraphQL const app = express(); const PORT = 3000; app.use('/graphql', graphlHTTP({ schema: schema, graphiql: true, }));
  25. 25. GraphQL
  26. 26. GraphQL Architecture Source: Apollo Server
  27. 27. GraphQL Terminology •Schemas and Types: •Define Object Types and Fields (Objects and Attributes •Queries => Select Statements •Mutations => Insert/Update Statements •Scalar => Custom Data Types •Resolver => Function that translates the type system to DB queries
  28. 28. abhaybhargav customary GraphQL Demo…
  29. 29. abhaybhargav Why Serverless AND GraphQL?
  30. 30. abhaybhargav
  31. 31. abhaybhargav
  32. 32. abhaybhargav
  33. 33. abhaybhargav
  34. 34. abhaybhargav
  35. 35. abhaybhargav
  36. 36. abhaybhargav
  37. 37. abhaybhargav
  38. 38. abhaybhargav
  39. 39. abhaybhargav Super-easy to deploy service: gql-sql-injection package: exclude: - node_modules - package-lock.json provider: name: aws runtime: nodejs8.10 timeout: 30 functions: graphql: handler: app.handler timeout: 30 events: - http: path: graphql method: post cors: false
  40. 40. abhaybhargav Security Considerations - FaaS • No* Frameworks => Back to Plain ol’ platform code • No Network Attack Surface • Observability/Debugging is a challenge • Events from Multiple Sources • Highly disciplined approach to Architecture Copyright - we45, 2018
  41. 41. abhaybhargav reading between the lines….
  42. 42. abhaybhargav Considerations - FaaS • No* Frameworks => Back to Plain ol’ platform code • No Network Attack Surface • Observability/Debugging is a challenge • Highly disciplined approach to Architecture Copyright - we45, 2018
  43. 43. abhaybhargav Considerations - FaaS • No* Frameworks => Back to Plain ol’ platform code • No Network Attack Surface • Observability/Debugging is a challenge • Highly disciplined approach to Architecture Copyright - we45, 2018 •No Batteries included Security Features (Frameworks)
  44. 44. abhaybhargav Considerations - FaaS • No* Frameworks => Back to Plain ol’ platform code • No Network Attack Surface • Observability/Debugging is a challenge • Highly disciplined approach to Architecture Copyright - we45, 2018 •No Batteries included Security Features (Frameworks) •DIY Validation
  45. 45. abhaybhargav Considerations - FaaS • No* Frameworks => Back to Plain ol’ platform code • No Network Attack Surface • Observability/Debugging is a challenge • Highly disciplined approach to Architecture Copyright - we45, 2018 •No Batteries included Security Features (Frameworks) •DIY Validation •Access Control per Function
  46. 46. abhaybhargav Considerations - FaaS • No* Frameworks => Back to Plain ol’ platform code • No Network Attack Surface • Observability/Debugging is a challenge • Highly disciplined approach to Architecture Copyright - we45, 2018 •No Batteries included Security Features (Frameworks) •DIY Validation •Access Control per Function •Logging Per Function
  47. 47. abhaybhargav Considerations - FaaS • No* Frameworks => Back to Plain ol’ platform code • No Network Attack Surface • Observability/Debugging is a challenge • Highly disciplined approach to Architecture Copyright - we45, 2018 •No Batteries included Security Features (Frameworks) •DIY Validation •Access Control per Function •Logging Per Function •and other things we don’t too too well…..
  48. 48. abhaybhargav Considerations - FaaS • No* Frameworks => Back to Plain ol’ platform code • No Network Attack Surface •Observability/Debugging is a challenge • Highly disciplined approach to Architecture Copyright - we45, 2018
  49. 49. abhaybhargav Considerations - FaaS • No* Frameworks => Back to Plain ol’ platform code • No Network Attack Surface •Observability/Debugging is a challenge • Highly disciplined approach to Architecture Copyright - we45, 2018 •Monitoring Attacks is a challenge unless you architect for it
  50. 50. abhaybhargav Considerations - FaaS • No* Frameworks => Back to Plain ol’ platform code • No Network Attack Surface •Observability/Debugging is a challenge • Highly disciplined approach to Architecture Copyright - we45, 2018 •Monitoring Attacks is a challenge unless you architect for it •Security Logging => FUHGEDDABOUDIT!
  51. 51. abhaybhargav Considerations - FaaS • No* Frameworks => Back to Plain ol’ platform code • No Network Attack Surface • Observability/Debugging is a challenge •Events from Multiple Sources Copyright - we45, 2018
  52. 52. abhaybhargav Considerations - FaaS • No* Frameworks => Back to Plain ol’ platform code • No Network Attack Surface • Observability/Debugging is a challenge •Events from Multiple Sources Copyright - we45, 2018 •Functions triggered from events like S3, SNS, SQS,etc
  53. 53. abhaybhargav Considerations - FaaS • No* Frameworks => Back to Plain ol’ platform code • No Network Attack Surface • Observability/Debugging is a challenge •Events from Multiple Sources Copyright - we45, 2018 •Functions triggered from events like S3, SNS, SQS,etc •Larger Attack Surface
  54. 54. abhaybhargav Considerations - FaaS • No* Frameworks => Back to Plain ol’ platform code • No Network Attack Surface • Observability/Debugging is a challenge •Events from Multiple Sources Copyright - we45, 2018 •Functions triggered from events like S3, SNS, SQS,etc •Larger Attack Surface •Traditional Security Controls - WAFs, etc may be ineffective
  55. 55. abhaybhargav Considerations - FaaS • No* Frameworks => Back to Plain ol’ platform code • No Network Attack Surface • Observability/Debugging is a challenge •Events from Multiple Sources Copyright - we45, 2018 •Functions triggered from events like S3, SNS, SQS,etc •Larger Attack Surface •Traditional Security Controls - WAFs, etc may be ineffective •DAST/Testing is hard to exec
  56. 56. abhaybhargav Useful Projects for Serverless Security Copyright - we45, 2018
  57. 57. abhaybhargav Attacker’s View of FaaS
  58. 58. abhaybhargav Routes to FaaS pwnage! • Attacking Function (and cloud provider) through non-API Gateway Events • Attacking Function (and Cloud Provider) through API (Web Services Attacks) • Identifying Vulnerabilities with IAM and Privileges => Elevation of Privs • Information Disclosure => Database Access, etc • Denial of Service Copyright - we45, 2018
  59. 59. abhaybhargav Function Data Event Injection
  60. 60. abhaybhargav What is Event Injection? • Injection Attacks triggered through Third party event notifications • Example: • File Uploaded to S3 • Message sent over Notification Service • Message received on Queue • DynamoDB Stream Events, • etc Copyright - we45, 2018
  61. 61. abhaybhargav Function Data Event Injection • Injection is back!! • Multiple Possibilities with Functions: • Insecure Deserialization • XXE • SQL Injection • NoSQL Injection • Server-Side Request Forgery • Template Injection
  62. 62. abhaybhargav Function Data Event Injection - Sources Command Injection SQL/NoSQL Injection Insecure Deserialization XXE
  63. 63. abhaybhargav Case Study User uploads XML laced with malware File Stores in Amazon S3 Notification triggers function Function reads uploaded file, XXE executes Attacker gains access
  64. 64. abhaybhargav Demo
  65. 65. abhaybhargav Challenges - Function Data Event Injection • Hard to test for => Execution is largely Out-of-Band • Hard to Protect with WAFs (other Network Security) => Several non-HTTP Protocols can be used to trigger this • Wide variety of execution scenarios
  66. 66. abhaybhargav Privilege Escalation - IAM Misconfiguration
  67. 67. abhaybhargav IAM & Other Misconfigurations • Permissions are often the greatest bugbear in a FaaS implementation • Devs tend to provide overly permissive capabilities for resources that interact with FaaS implementations • Permissions are usually set in cloud IAM environments with Policies, Roles, etc • This includes misconfigurations like Public S3 buckets and access to all DynamoDB tables, etc
  68. 68. abhaybhargav Examples of IAM - Effect: Allow Action: - 'dynamodb:*' Resource: - 'arn:aws:dynamodb:us-east-1:****************:table/TABLE_NAME' Allows ALL actions on a DynamoDB Table - Effect: Allow Action: - dynamodb:PutItem Resource: 'arn:aws:dynamodb:us-east-1:****************:table/TABLE_NAME' Only PUT allowed on Table
  69. 69. abhaybhargav DynamoDB Injection client.scan(TableName = 'dynamo-user', Select = 'ALL_ATTRIBUTES', ScanFilter = { 'first_name': {"AttributeValueList": [{"S": "Joe"}], "ComparisonOperator": "EQ"} }) Standard “scan” with DynamoDBEQ|NE|IN|LE|LT|GE|GT|BETWEEN| NOT_NULL|NULL|CONTAINS| NOT_CONTAINS|BEGINS_WITH client.scan(TableName = 'dynamo-user', Select = 'ALL_ATTRIBUTES', ScanFilter = {'first_name': {"AttributeValueList": [{"S": "*"}], "ComparisonOperator": "GT"}}) Equivalent of ‘OR 1=1, Retrieves all values from the Table
  70. 70. abhaybhargav Demo
  71. 71. abhaybhargav Other Weaknesses • Authorization Weaknesses especially with JSON Web Tokens (JWTs) • Denial of Service Attacks based on Library weaknesses • Dynamic Testing is a major challenge for Serverless Functions • SAST/SCA becomes the way to go. But gets hard with multiple language implementations Copyright - we45, 2018
  72. 72. abhaybhargav Attacker’s view of GraphQL
  73. 73. abhaybhargav Security Considerations - GraphQL Copyright - we45, 2018
  74. 74. abhaybhargav Security Considerations - GraphQL • Access Control Copyright - we45, 2018
  75. 75. abhaybhargav Security Considerations - GraphQL • Access Control • Input Validation Copyright - we45, 2018
  76. 76. abhaybhargav Security Considerations - GraphQL • Access Control • Input Validation • Query Whitelisting Copyright - we45, 2018
  77. 77. abhaybhargav Security Considerations - GraphQL • Access Control • Input Validation • Query Whitelisting • Rate Limiting Copyright - we45, 2018
  78. 78. abhaybhargav Security Considerations - GraphQL • Access Control • Input Validation • Query Whitelisting • Rate Limiting Copyright - we45, 2018 }
  79. 79. abhaybhargav Security Considerations - GraphQL • Access Control • Input Validation • Query Whitelisting • Rate Limiting Copyright - we45, 2018 }
  80. 80. abhaybhargav Attacker’s View of GraphQL Copyright - we45, 2018
  81. 81. abhaybhargav Attacker’s View of GraphQL • Similar set of flaws as you would see with any other Web App/Web Service Copyright - we45, 2018
  82. 82. abhaybhargav Attacker’s View of GraphQL • Similar set of flaws as you would see with any other Web App/Web Service • Authorization Flaws and Info Disclosure Flaws take center-stage Copyright - we45, 2018
  83. 83. abhaybhargav Attacker’s View of GraphQL • Similar set of flaws as you would see with any other Web App/Web Service • Authorization Flaws and Info Disclosure Flaws take center-stage • NoSQL Flaws might be big with GraphQL Apps Copyright - we45, 2018
  84. 84. abhaybhargav Attacker’s View of GraphQL • Similar set of flaws as you would see with any other Web App/Web Service • Authorization Flaws and Info Disclosure Flaws take center-stage • NoSQL Flaws might be big with GraphQL Apps • Make Denial-of-Service Great Again! Copyright - we45, 2018
  85. 85. abhaybhargav GraphQL Introspection (Information Disclosure)
  86. 86. abhaybhargav Introspection? Copyright - we45, 2018
  87. 87. abhaybhargav Introspection? Copyright - we45, 2018
  88. 88. abhaybhargav Introspection? Copyright - we45, 2018
  89. 89. abhaybhargav Introspection? Copyright - we45, 2018
  90. 90. abhaybhargav Authorization Bypass
  91. 91. abhaybhargav Anyone remember Mass Assignment? Copyright - we45, 2018
  92. 92. abhaybhargav Demo
  93. 93. abhaybhargav Injection
  94. 94. abhaybhargav Injection with GraphQL • Unlike REST (single query per function), GraphQL resolvers are written for a larger query space • With NoSQL databases, this could lead to injection (and probably RCE) if Dynamic Scripting is enabled (Mongo, Elasticsearch, etc) Copyright - we45, 2018
  95. 95. abhaybhargav Demo
  96. 96. abhaybhargav DoS
  97. 97. abhaybhargav Nested Queries - Resource Exhaustion • Nested Queries with Many to Many Fields can be easily scaled to “high cost” queries • When coupled with FaaS invocations, can really add up the costs Copyright - we45, 2018
  98. 98. abhaybhargav Demo Copyright - we45, 2018
  99. 99. abhaybhargav Conclusions • Serverless and GraphQL Stacks are going to be big moving forward • Developers need to largely DIY Implementations => Few Frameworks today! • Security Tooling => Needs to catch up a WHOLE LOT MORE! Copyright - we45, 2018
  100. 100. abhaybhargav Thanks! •Twitter: @abhaybhargav •Website and Blog: www.we45.com •Product: www.orchestron.io Copyright - we45, 2018

×