This new _xsrf=1 cookie will then be sent to all subdomains of. home/ec2-user/anaconda3/envs/JupyterSystemEnv/share/jupyter/lab/static/index.html sagemaker.aws so it will be sent to all its subdomains.ĭokie='_xsrf=1 Domain=. I decide to use the self XSS to create a new cookie named_xsrf and the domain attribute will be. Therefore, we can have 2 cookies with the same name if they have a different domain or path. I consider that maybe I can use cookie tossing …Ĭookie keys consists of the tuple (name, domain, path). In such an environment where each user gets its own subdomain under the same parent domain, it is interesting to have a look at the cookies: And to be more specific – all are under the subdomain of. Maybe this isn’t so useful… Or is it? Cookies to the RescueĪs I mentioned at the beginning, all JupyterLabs Notebooks in SageMaker are created under the same parent domain. This is clearly an XSS – but it is self XSS □ We can change its content and control what is running when browsing to: I used the terminal in the JupyterLab to list the files in the static directory and found index.html home/ec2-user/anaconda3/envs/JupyterSystemEnv/share/jupyter/lab/static One interesting path was the staticDir that pointed to Viewing the source of the main page exposes some interesting paths located on the VM running the JupyterLab application. This thread follows my thought process as I reveal the path to my findings. The following is a rundown of my path to the discovery of the AWS SageMaker Notebook Instance Takeover. I decided to play around with this environment and explore potential gaps, so I created a Notebook Instance named “gafnb” where .aws is its designated JupyterLab domain. Usually, the unique subdomain will be the name we give the Notebook Instance at the time of creation, but if the subdomain has already been taken, AWS adds some random values to the end of the subdomain. parent domain (where us-east-1 can be replaced with a different region). When we create a Notebook Instance in AWS SageMaker a new JupyterLab environment is created with a unique subdomain under the. It provides an integrated Jupyter notebook instance for easy access to your data sources for exploration and analysis, so you don't have to manage servers. With SageMaker, data scientists and developers can quickly and easily build and train machine learning models, and then directly deploy them into a production-ready hosted environment. IntroĪmazon SageMaker is a fully managed machine learning service. We reported the vulnerability we discovered to the AWS security team, and they have since remediated it. Using the access token, the attacker can read data from S3 buckets, create VPC endpoints and more actions that are allowed by the SageMaker execution role and the “AmazonSageMakerFullAccess” policy. This means that an attacker can access the Notebook Instance metadata endpoint and steal the access token for the attached role. We found that an attacker can run any code on a victim’s SageMaker JupyterLab Notebook Instance across accounts. Here is the long and short of our recent discovery. During our research about security in data science tools we decided to look at Amazon SageMaker which is a fully managed machine learning service in AWS.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |