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.
12. abhaybhargav
What is FaaS?
• Functions that are triggered via events => Triggering a Container/VM
Copyright - we45, 2018
13. abhaybhargav
What is FaaS?
• Functions that are triggered via events => Triggering a Container/VM
• Execute (thing)
Copyright - we45, 2018
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. 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
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
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
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
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
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
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. 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
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
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
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. 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. 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
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
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. 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. 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. 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
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
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
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