DEV Community: rosswilliams

Fun with Amplify Default Permissions

rosswilliams — Sun, 24 May 2020 20:22:03 +0000

Note: This is an exercise in understanding AWS Amplify API KEY Auth and Storage configuration in order promote more secure application development. Please use this information to better protect and monitor your applications.

How to use someone else's AWS account to create a platform to share and store an unlimited amount of data.

AWS Amplify is described as a platform for building scalable and secure mobile and web applications, allowing developers to design and deploy a backend in just 30 minutes. For this tutorial we will use the scalable part of the platform. What is important is that out of the box, Amplify doesnn't help much with business logic. In 30 minutes a CRUD API can be setup, and can be connected with S3 for storage. Of course, an open CRUD API without any type of validation isn't an app, it's an invitation for abuse. Let's use it to create our own app, Sharebox. Sharebox has a simple goal, allow any user to upload an unlimited amount of files, and allow anyone else to download these files, all at zero cost (to us).

The key is to find an Amplify application with S3 storage configured and allows unauthenticated requests. When an Amplify app uses API keys
to grant access to cloud resources, it uses Amazon Cognito to create temporary AWS credentials to access resources. In order for us to use another app's database the only thing we need to do is find the Cognito endpoint used to fetch these credentials. Luckily a simple peek at the network tab while interacting with an app is sufficient.

Once we have the credentials, we can interact with AppSync to manage the database, and we can use Amazon S3 to store and read large file object.

Finding one of these projects is probably the hardest part, so watch on popular websites for posts about Amplify and how quickly a backend was stood up, and especially where the app appears to support image uploads.

Let's imagine we found a CV review service, and that the developer lives in a region where attaching a photo to a CV is common practice. The schema.graphql file may look like the below, which you could also determine by looking at the AppSync API schema introspection endpoint

# Other types elided...

type Candidate @model {
    id: ID!
    cvCandidatesId: ID
    name: String! # The CV user's name
    userScore: Int! #0-100
    image: String # Photo to attach to CV
}
type CV @model {
    id: ID!
    cvData: String!
    candidate: Candidate @connection
}

The API object we will (ab)use in this case is the Candidate model, since it appears we can insert data that will be well hidden, as the frontend of the web app never queries this data directly, but instead works through the CV model. With this model we can build our own API. For our Sharebox app we need to use the 'id', 'name', 'image', and 'userScore' field. For our app we will re-purpose 'image' to be the S3 bucket path for the data we store, 'id' and 'name' are self-explanatory, and we will set 'userScore' to -100 so we can filter in the database to only return our Sharebox related data.

Now we can utilise the GraphQL CRUD API to insert our first item's metadata:

mutation {
    createCandidate(input: { 
        name: "a very large video",
        userScore: -100,
        image: "bucketName/public/Sharebox/myBigVideo1.mp4"
    }) {
        id
    }
}

And read it out again:

query {
    listCandidates(limit: 999, filter: {userScore: {lt: -99 }}) {
        name
        image
    }
}

To run these graphql queries, use aws4fetch to make the request, and pass in access key, secret key, and session token fetched from Cognito.

Now the only part remaining is to insert the video into S3 and read it out.

Inserting data is equally easy, using the same aws4fetch library we can create a signed request to utilise the bucket, and then upload the file with a normal fetch request. A nice trick at this point is to set the 'x-amz-acl' request header to 'public-read'. This way we don't need to construct a signed URL to retrieve the data. Note that the bucket path must begin with 'public/', as by default this is the prefix Amplify sets aside for non-authenticated users.

Reading out the data at this point is an easy fetch.

To build out a frontend, we can use Cognito to get credentials, list our files from the Candidate model, offer links to download any file, and have a file upload utility which gets a presigned url and allows an upload. When the upload finishes we can insert a not database item in the Candidate model and give the file a custom name to display in our UI.

There are some downsides. First, any user can delete an item in S3 and our data could become inconsistent. Second, our app only works so long as someone provides a free open bucket and API. And third, anyone with billing notifications on will soon get an alert and shut this app down.

AWS Amplify's Security UX is Insufficient and Dangerous

rosswilliams — Sun, 11 Aug 2019 13:47:12 +0000

Amplify is a Backend as a Service toolset with the goal of allowing developers to build cloud applications without advanced knowledge of the underlying infrastructure. The goal of focusing developers on creating business logic is laudable, but the toolset is not without weaknesses. Some weaknesses are missing features due to the product being new and these are understandable, but protecting customers needs to come before any new features and be priority #1 at AWS. Unfortunately, the Amplify authorisation tools do not sufficiently protect customers from exposing private data. Protecting customers has not been the highest priority.

Amazon has dealt with these issues before. S3, launched in 2006, is infamous for being hard for customers to configure securely. Data breaches from Capital One, Facebook, Verizon, Time Warner, and the USA Department of Defence are just some of the larger AWS S3 customers who have leaked data due to hard to understand and hard to verify security configurations. Some of the S3 data leaks are due to poor UX, with policies to lock down buckets to "any authenticated AWS user", which in practice means any user globally who spends 5 minutes registering an account. Basic security checks from an unauthenticated user would show these buckets are not available, where in reality a bad actor could scoop up company secrets in minutes.

Amazon has responded to these events by creating more tools to help customers identify open buckets and design better default policies. But there is only so much that can be done without breaking a decade of existing users. The result is that Chris Vickery, Director of Cyber Risk Research at UpGuard, is still seeing the same level of data breaches as before. The economic impact of not protecting S3 customers as priority #1 is measured in the billions of dollars. And now AWS Amplify is heading down the same path unless immediate corrections are made.

The crux of the issue is that Amplify markets its authentication modules to "provide Authentication APIs and building blocks for developers who want to create apps with real-world production-ready user authentication". Multiple AWS documents show how Amplify can accomplish proper authZ controls through Graphql directives. In the simple case of a note taking app, AWS sample code shows the following snippet, explaining to the user that "These items are only available to the user that created them":

type Note @model @auth(rules: [{ allow: owner }]) {
    id: ID!
    title: String!
    content: String
}

And to the casual reader, or even developer on a team using Amplify, this appears secure. Unfortunately, any user can read these notes as they are created or modified. How? Easy, every model by default creates a graphql subscription, which when called returns for any user an AWS IoT endpoint for MQTT over WSS, where you can subscribe to the returned topic and listen to all create and update events for a model. So much for users not needing to have advanced knowledge of the underlying infrastructure. On the majority of Amplify projects I have examined which proport to implement private data, subscriptions are available to read private information. While security is everyone's job, and every developer should be a security engineer, blame does not solely fall on these implementors, as they have been told that Amplify is doing the heavy lifting for them. Discovering the issue would have forced developers down the path of understanding unfamiliar languages and products they likely didn't know existed.

Until a month ago the Amplify documentation did not even acknowedge subscriptions can and do leak private information and how to turn them off, though users stumbling on the issue have notified AWS for much longer. Now, after an hour of reading time, and inside a page that takes at least 2 hours to read, is a note: "The @auth directive does not yet support subscriptions out of the box. Currently, you have two options for authorising subscription fields. You may turn off subscriptions by passing subscriptions: null to @model or you may write custom authorisation logic". Unfortunately, this note hasn't resulted in updates to "How to have a secure Amplify project in 60 minutes" tutorials, including those published by AWS, where users are likely to copy solutions as a starting point.

But its not only subscriptions, making models seachable likewise bypasses authentication. The AWS Amplify workshop, published and copyrighted by AWS, contains the following graphql schema:

type Photo 
  @model 
  @auth(rules: [{allow: owner}]) 
  @searchable {
    id: ID!
    album: Album @connection(name: "AlbumPhotos")
    bucket: String!
    fullsize: PhotoS3Info!
    thumbnail: PhotoS3Info!
    labels: [String!]
}

Again a casual reader, developer taking the workshop, or developer on a team using Amplify would assume this authentication role properly protects the Photo model. And the Amplify workshop page further states this schema "add[s] the ability for other people view and upload to our albums on a case-by-case basis". While that statement is true for the generated listPhotos and getPhotos graphql queries, it is not true for the searchPhotos query. Amplify users can verify this by inspecting the velocity template code generated by amplify during the deployment process. What they can't do is find this security bypass in the Amplify documentation. This authentication bypass has been flagged as an issue since November 2018 and appears to be a deliberate tradeoff to add a feature faster vs. integrate into the authorisation system. In the meantime developers are left on their own to discover this security hole, and learn to write velocity templates to implement their own security.

Everyone is responsible for building secure systems, including tool users and providers. Amplify users must evaluate and verify claims the tooling makes. Trust but verify. At the same time AWS markets Amplify as being able to abstract away complex back end and cloud technologies, and by implication state they are shifting the dividing line in the shared responsibility model to take on additional security responsibilities. And it is disappointing that this responsibility is being marketed to developers when the Amplify tool does not fulfill its obligation to create tools to properly control sensitive data.

Some Amplify marketing claims have failed the verification test. Users do need to worry about spending time on the heavy listing of configuring and securing multiple different cloud back-end services to power their applications. Failure to maintain responsibility for security will put businesses and their customers at risk.

These security issues can be overcome by users implementing additional custom logic and understanding more of the cloud technologies Amplify is creating on their behalf. Amplify does not have inherent security issues, and the tools can be evolved to create solutions that satisfy the marketing and tutorial claims. But some changes to Amplify may introduce breaking changes for existing users. And everyday these known issues are not addressed, more users will have implemented insecure systems and trap AWS into less than ideal upgrade paths. The Amplify team is in control over how many news stories in the next decade will discuss security breaches due to mis-configured Amplify APIs.

I hope the above will highlight to existing users they need to check the security of their own systems for these risks. And I hope AWS re-focuses their efforts on Amplify to follow their CTOs advice that protecting customers comes before any feature development.